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^mbers of simultaneous users; e.g. millions, with access to a 
Targe number; e.g. thousands, of applications which may include 
pre-created, interactive text/graphicf sessions; and more 
particularly, to a computer network in which the interactive 
text/graphic sessions are comprised /of pre-created blocks of data 
and program instructions which may toe distributed downwardly in 
the network for use at a software Enhanced user computer terminal 
that reduces processing demand on/the higher-level network 
elements, thus permitting the higher-level elements to function 
primarily as data supply and maintenance resource, and, thereby, 
reduce network complexity, cost land response time. 

Interactive computer networks /are not new. Traditionally they 
have included conventional, hierarchical architectures wherein a 
central, host computer responds! to the information requests of 
multiple users. An illustrative example would be a time-sharing 

at remote terminals log onto a 
loftware resource which 
processing requests, executes 
them and supplies responses bafck to the users. 

While such networks have madL the processing power of large 
computers available to many users, the problem has been that in 
such networks, the host is required to satisfy all the user data 
processing requests. This, however, creates processing bottle- 
necks at the host which tax the host resources and require 
increased computing power; i.e., bigger and more complex computer 
facilities, to meet demand as the number of users is increased. 
Still further, occurrence of Luch bottlenecking also increases 
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network in which multiple users 
host computer having data and si 
sequentially receives user data 



^^twork response time to unacceptabl 
users is increased. 



<> levels as the number of 



The size and complexity of the network host, however, is 
particularly critical in the case of commercial interactive 
computer network recently introducep to offer large number of the 
general public text and graphics information to permit not only 
at home shopping and financial management such as banking and 
bill paying, but also the providing of information relating to 
entertainment, business and personal matters. 



N 

m 

111 



00 

m 



As can be appreciated, in such state of the art information and 
shopping networks, the network must be able to provide the 
information and shopping services with a minimal amount of 
network resources in order to maintain the capital investment in 
the network at a level that rendJers the services economical to 
use. Unlike military and governmental networks in which capital 
investment is a secondary concern because of the importance of 
the service provided, in commercial information and shopping 
services, the capital investment in the network resources must be 
kept low in order to make the rletwork affordable both to the 

on the network as a channel of 
'or services. Further, in addi- 



users and those who would rely 
distribution for the goods and/ 



tion, to maintaining capital investment at a minimum, it is also 
desirable to maintain network response time at a minimum in order 
to not only capture and hold tie user's attention, but also 
quickly free the network to satisfy the requests of other users. 
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noted, this ability to satisfy Requests with minimal network 
resources is required to enable the network to serve large 
numbers of users and, thereby, rerJder the network economical to 
use . 

While conventional, previously known time-sharing network 
designs have attempted to alleviate host completely and response 
time problems by providing some processing at the user site; 
i.e., "smart terminals" , still the storage of the principal data 
and software resources needed for processing at the host contin- 
ues to create a burden on network complexity and response time 
which renders the conventional abproach unsuited for the large 
numbers of users required for a /commercially viable computer 
based information and shopping network. 

SUMMARY OF INVENTION 
Accordingly, it is an object of this invention to provide 



method and apparatus which per: 



it a very large number of users to 



obtain access to a large numbef of applications which include 
interactive text/graphic sessions that have been created to 
enable the users to obtain information and transactional services 
such as shopping events . 



It is a further object of th 
apparatus which permit the dat^ 
applications including interact 
distributed over a computer network 



is invention to provide method and 
and programs necessary to support 
ive text/graphic sessions to be 



* 



^ It is a still further object of this invention to provide 
software that will enable a conventional personal computer to be 
coupled to a computer network uo establish a reception system 
suitable for supporting applications which include interactive 
text/graphic sessions created /to enable the user to obtain 
information and conduct shopping events. 



It is yet another object of this invention to provide method 
and apparatus that would penmit information and transactional 
services to be provided to users based upon predetermined parame- 
ters such as user demographics and/or locale. 
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It is yet another object of the invention to provide method and 
apparatus capable of collecting data regarding usage of the 
network and to condition the applications and the included 
text/graphics sessions ba£ed upon the reactions to the applica- 
tions by the users. 



Briefly, to achieve the 



above and other objects and features, 



the invention includes method and apparatus for providing 
interactive applications containing text and graphics at the 
monitor of a personal computer, wherein the personal computer has 
been configured as a reception system by the inclusion and 
running of reception system software that enables the reception 
system so formed to be electronically connected to a network 
specially adapted to create, maintain and supply databases and 
portions thereof containing the applications on demand. In 
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^cordance with its method aspects, the invention includes 
procedures for formulating objects that have been specially 
structured to include display and control data and program 
instructions for supporting the applications at the network 
reception systems, the objects being pre-created, parceled units 
of information that may be distributed and stored at lower levels 
in the network, and particularly the reception system, so as to 
reduce processing demand on the network higher element, and there 
by permit the higher elements to function primarily as elements 
for maintaining and supplying the database information. 

/? 



□ Further, in preferred f ofcm/C j?he method aspect of the invention, 



W features use in combination wil4^£^ specially formulated 

objects, of specially structured messages that harmonize and 
facilitate communications between the different elements of the 
network and computing elements external to the network that may 
be called upon to supply information to support the applications, 



CO Also in preferred form, the method aspect of the invention 

features specially prepared program instructions included within 
the objects that permit the objects to be executed at the recep- 
tion system in conjunction with the application software. 

Also in preferred form, the invention includes procedures in 
the form of application software that contain modules that 
individually and in combination facilitate the execution of 
objects and the handling of messages at the reception system so 
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^piat the interactive sessions may be supported at the reception 
system. 

Still further in its apparatus, aspects the invention includes 
a reception system comprised of a plurality of types of personal 
computers combined with the application software for use in the 
interactive network for displaying information and providing 
transactional services to a plurality of users, the reception 
system further comprising in preferred form input means for 
receiving user inputs; storage means for storing objects contain- 
ing data or interpretively executable programs, the objects 
£3 comprising a plurality of partitioned applications; and object 
y processing means, responsive to the input means, for selectively 
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retrieving objects from the storage means and interpreting and 



executing the partitioned applications. 

Si / '/• , . 



*J DESCRIPTION OF THE DRAWINGS. 
SI /> 



U The above and further objects, features and advantages of the 



£f| invention will become clear from the following more detailed 

description when read with reference to the accompanying drawings 
in which: 



FIG. 1 is a block diagram of the interactive computer network 
in accordance with the invention; 

FIG. 2 is a schematic diagram of the network illustrated in 
FIG. 1; 
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Figures 3(a) and 3(b) are plan views of a display screen 
presented to a user in accordance with the invention; 

Figures 4(a), 4(b), 4(c) and 4(d) are schematic drawings that 
illustrate the structure of objects, and object segments utilized 
within the interactive network in accordance with the invention; 

FIG. 5(a) is a schematic diagram that illustrates the config- 
uration of the page template object in accordance with the 
invention; 

S FIG, 5(b) is a schematic diagram ;> that illustrates page 

composition in accordance with the invention; 



CO 

1^ FIG. 6 is a schematic diagram that illustrates the protocol 

m . ... 

used by the reception system to support user applications in 

*w? accordance with the invention; 
M 

ry 



f!y FIG. 7 is a schematic diagram that illustrates major layers 

of the reception system in accordance with the invention; 



FIG. 8 is a block diagram that illustrates native code 
modules of the reception system in accordance with the invention; 

FIG. 9 is a schematic diagram that, illustrates an example 
of a partitioned application to be processed by the reception 
system in accordance with the invention; 
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^ FIG. 10 illustrates generation of a page with a page pro- 
cessing table in accordance with the invention; 

FIG. 11 is a table that lists the TBOL verbs in accordance with 
the invention; and 

FIG* 12 is a block diagram of the reception system in 
accordance with the invention. 



DESCRIPTION OF THE PREFERRED EMBODIMENT 



O GENERAL SYSTEM DESCRIPTION 



In 



With reference to Fig^Ol, the invention includes a reception 
system (RS) 400 within interactive computer network 10 for 
displaying information and providing transactional services. In 



this arrangement, a plurality of users each access network 10 



with a conventional personal computers, for example one of the 
09 

65 IBM-compatible or Apple type, which has been provided with 

applications software in accordance with the invention so as to 
constitute RS 400. 



As shown in Fig. 1, interactive network 10 uses a layered 
structure that includes an information layer 100, a switch/file 
server layer 200, and cache/concentrator layer 300 as well as 
reception layer 401. This structure maintains active application 
databases and delivers requested parts of the databases on demand 
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^> the plurality of RS 400's, better seen in FIG. 2. As also 
shown in FIG. 2, cache/concentrator layer 3 00 includes a plurali- 
ty of cache/concentrator units 302, each or which serve a plural- 
ity of RS 400 units over lines 301. Additionally, switch/file 
server layer 200 is seen to include a server unit 205 connected 
to multiple cache/concentrator units 302 over lines 201. 4 Still 
further, server unit 2 05 is seen to be connected to information 
layer 100 and its various elements, which act as means for 
producing, supplying and maintaining the network databases and 
other information necessary to support network 10. Continuing, 
switch/filer layer 200 is also seen to include gateway systems 
210 connected to server 205. Gateways 201 couple layer 200 to 
other sources of information and data; e.g., other computer 
systems. As will be appreciated by those skilled in the art, 
layer 200, like layers 401 and 300 could also include multiple 
servers, gateways and information layers in the event even larger 
numbers of users were sought to be served. 

Continuing with reference to Fig. 2, each RS 4 00 is seen to 
include a personal computer 4 05 having a CPU 410 including a 
microprocessor (as for example the type made by INTEL Corporation 
in its X x 86 family of microprocessors), companion RAM and ROM 
memory and other associated elements, monitor 412 with screen 414 
and a keyboard 424. Further, personal computer 405 may also 
include one or two floppy disk drives 42 6 for receiving diskettes 
416 containing application software in accordance with this 
invention for supporting the interactive sessions with network 10 



^^id diskettes 428 containing operating systems software suitable 
for the personal computer 405 being used. Personal computer 4 05 
may also include a hard disk drive 420 for storing the applica- 
tion software and operating system software which may be trans- 
ferred from diskettes 42 6 and 428 respectfully. 

Once so configured, each RS 400 provides: a common interface to 
other elements of interactive computer network 10; a common 
environment for application processing; and a common protocol for 
user - application conversation which is independent of the 
personal computer type used. RS 400 thus creates a universal 
terminal for which only one version of all applications on 
network 10 need be prepared, thereby rendering the applications 
interpretable by the major brands of personal computers. 

RS 400 formulated in this fashion is capable of communica- 
tion with the host system to receive information containing 
either of two types of data, namely objects and messages. 
Objects have a uniform, self-defining format known to RS 400, and 
include data types, such as interpretable programs and presenta- 
tion data for display at monitor screen 414 of the user's person- 
al computer. Applications presented at RS 400 are partitioned 
into objects which represent the minimal units available from the 
higher levels of interactive network 10 or RS 400. In this 
arrangement, each application partition typically represents one 
screen or a partial screen of information, including fields 
filled with data used in transactions with network 10. Each such 



^ireen, commonly called a page, is represented by its parts and 
is described in a page template object, discussed below. 



Applications, having been partitioned into minimal units, 
are available from higher elements of network 10 or RS 4 00, and 
are retrieved on demand RS 400 for interpretive execution. Thus, 
not all partitions of a partitioned application need be resident 
at RS 400 to process a selected partition, thereby raising the 
storage efficiency of the user's RS 400 and minimizing response 
time. Each application partition is an independent, self-con- 
tained unit and can operate correctly by itself. Each partition 
© may refer to other partitions either statically or dynamically. 
Static references are bv^w/tti-to the partitioned application, 
while dynamic references are treated from the execution of 
program logic using a set of paraim^ers, such as user demograph- 
ics or locale.. Partitions may be chosen as part of the RS 
processing in response to user created events, or by selecting a 
key word of the partitioned application (e.g., "JUMP" or "INDEX," 
discussed below) , which provides random access to all services 
represented by partitioned applications having key words. 



in 



Objects provide a means of packaging and distributing 
partitioned applications. As noted, objects make up one or more 
partitioned applications, and are retrieved on demand by a user's 
RS 4 00 for interpretive execution and selective storage. All 
objects are interpreted by RS 400, thereby enabling applications 
to be developed independently of the personal computer type used. 
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Objects may be nested with one another or referenced by an 
object identifier (object-id) from within their data structure. 
References to objects permit the size of objects to be minimized. 
Further, the time required to display a page is minimized when 
referenced objects are stored locally at RS 400 (which storage is 
determined by prior usage meeting certain retention criteria) , 
or have been pre-f etched, or in fact, are already used for the 
current page. 

Objects carry application programs and information for 
display at monitor screen 414 of RS 400. Application program 
Q objects, called preprocessor and post-processors, set up the 
y environment for the user's interaction with network 10 and 
jjg respond to events created when the user inputs information at 
fS keyboard 424 of RS 400. Such events typically trigger a program 

frjr a 

^ object to be processed, causing one of the following: sending of 
O transactional information tfc/$z6^ co-applications in one layer of 
TU the network 10; the receiving of^ ^n£6rmation for use in programs 
or for presentation in application-dej^ident fields on monitor 
screen 414; or the requesting of a new objects to be processed by 
RS 400. Such objects may be part of the same application or a 
completely new application. 



*0 



The RS 4 00 supports a protocol by which the user and the 
partitioned applications communicate. All partitioned applica- 
tions are designed knowing that this protocol will be supported 
in RS 400. Hence, replication of the protocol in each 

-13- 



^^rtitioned application is avoided, thereby minimizing the size 
of the partitioned application - 



RS 4 00 includes a means to communicate with network 10 to 
retrieve objects in response to events occurring at RS 400 and to 
send and receive messages. 

RS 4 00 includes a means to selectively store objects accord- 
ing to a predetermined storage criterion, thus enabling frequent- 
ly used objects to be stored locally at the RS , and causing 
infrequently used objects to forfeit their local storage loca- 
tion. The currency of objects stored locally at the RS 400 is 
verified before use according to the object's storage control 
parameters and the storage criterion in use for version checking. 

S 1 Selective storage tailors the contents of the RS memory to 

P contain objects representing all or significant parts of parti- 

M C > > 

ry tioned applications favore^^^ihe user. Because selective 

m cxv 

££l storage of objects is local, r&sjpojase time is reduced for those 
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partitioned applications that the &s<$ accesses most frequently. 

Since much of the application processing formerly done by a 
host computer in previously known time-sharing networks is now 
performed at the user's RS, the high elements of network 10, 
particularly layer 200 has its primary functions routing messag- 
es, serving objects, and line concentration. The narrowed 
functional load of the higher network elements permits many more 
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^ers to be serviced within the same bounds of computer power and 
I/O capability of conventional host-centered architectures. 



Network 10 provides information on a wide variety of topics, 
including, but not limited to news, industry, financial needs, 
hobbies and cultural interests. Network 10 thus eliminates the 
need to consult multiple information sources, giving users an 
efficient and timesaving overview of subjects that interest them. 

The transactional features of interactive network 10 saves 

the user time, money, and frustration by reducing time spent 

□ traveling, standing in line, and communicating with sales person- 
Si 

yj nel . The user may, through RS 400, bank, send and receive 

ffs messages, review advertisements, place orders for merchandise, 

y* and perform other transitions. 

iff* * ^V" 

>tF - <^ . 

w In the preferred embodiment," Network 10 provides information 

f «i. 3 

PJ and transaction processing services for a large number of users 
fig simultaneously accessing the network via the public switched 
telephone network (PSTN) , broadcast, and/or other media with 
their RS 400 units. Services available to the user include 
display of information such as movie reviews, the latest news, 
airlines reservations, the purchase of items such as retail 
merchandise and groceries, and quotes and buy/sell orders for 
stocks and bonds. Network 10 provides an environment in which a 
user, via RS 400 establishes a session with the network and 
accesses a large number of services. These services are 
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specifically constructed applications which as noted are 
partitioned so they may be distributed without undo transmission 
time, and may be processed and selectively stored on a user's RS 
400 unit. 



SYSTEM CONFIGURATION 



As shown in FIG.l, in preferred form interactive computer 
network 10 includes four includes layers: information layer 100, 
switch and file server layer 200, concentrator layer 300, and 
Cp reception system 4 00. 



SI 



gg Information layer 100 handles:;. /(I) the production, storage 

and dissemination of data and (2) the, ejection and off-line 



** s processing of such data from each RS session with the network 10 

0 so as to permit the targeting of information to be presented to 

SI 

fU users and for traditional business support. 

C8 

Switch and file server layer 200 and cache concentrator 
layer 3 00 together constitute a delivery system 20 which delivers 
requested data to RS 4 00 and routes data entered by the user or 
collected at RS 400 to the proper application in network 10. 
With reference to FIG. 2, the information used in the RS 4 00 
either resides locally at the RS 400, or is available on-demand 
from the cache concentrator 300 or a the file server 205, via the 
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^^teway 210, which may be coupled to external providers, or is 
available the from information layer 100. 



There are two types of information in the network 10 which 
are utilized by the RS 4 00: objects and messages. 

Objects include the information requested and utilized by 
the RS 4 00 to permit a user to select specific parts of applica- 
tions, control the flow of information relating to the applica- 
tions, and to supply information to the network. Objects are 
self-describing structures organized in accordance with a specif- 
ic data object architecture, described below. Objects are used 
to package presentation data and program instructions required to 
support the partitioned applications of a RS 400, Objects are 
distributed on demand throu^o^t interactive network 10. Objects 



may contain: control inf ormatibS,v tafragram instruction to set up 
an application processing environmertt£y&nd to process user or 
network created events; information about what is to be displayed 
and how it is to be displayed; references to programs to be 
interpretively executed; and references to other objects, which 
may be called based upon certain conditions or the occurrence of 
certain events at the user's personal computer, resulting in the 
selection and retrieval of other partitioned applications pack- 
aged as objects. 



Messages are information provided by the user or the network 
and are used in fields defined within the constructs of an 
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^^ject, and are seen on the user's R.S. monitor, or are used for 
data processing at RS 400. Additionally, and as more fully 
described hereafter, messages are the primary means for communi- 
cation within and without the network. The format of messages is 
application dependent. If the message is input by the user, it 
is formatted by the partitioned application currently being 
processed on RS 4 00. Likewise, and with reference to FIG. 2, if 
the data are provided from a co-application database residing in 
delivery system 20, or accessed via gateway 210 or high function 
system 110 within the information layer 100, the partitioned 
application currently being processed on RS 4 00 causes the 

Q message data to be displayed in fields on the user's display 

SI 

yj monitor as defined by the particular partitioned application. 



jU; Objects recently introduced into delivery system 2 0 from the 
fU producer system 120 will be available from file server 205, but 



may not be available on cache/concentrator 3 02 to which the 
user's RS 400 has dialed. If such objects are requested by the 
RS 400, the cache controller automatically requests the object 
from file server 2 05. The requested object is routed back to the 
requesting cache/concentrator 302, which automatically routes it 
to the communications line on which the request was originally 
made, from which it is received by the RS 4 00. 



m 




objects or objects in preparation ^ 



e server 205. 



in producer system 120. 



Inactive 
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^ The RS 400 is the point of application session control 
because it has the ability to select and randomly access objects 
representing all or part of partitioned applications and their 
data. RS 4 00 processes objects according to information con- 
tained therein and events created by the user on personal comput- 
er 405. 

Applications on network 10 act in concert with the distrib- 
uted partitioned applications running on R.S.400. Partitioned 
applications constructed as groups of objects are distributed 
on-demand to a user's R.S.400. Partitioned applications repre- 
sent the minimum amount of information and program logic needed 
to present a page or window, i.e. portion of a page presented to 
the user, perform transactions with the interactive network 10, 
and perform traditional data processing operations, as required, 
including selecting another partitioned application to be 
processed upon a user gq^^^t^d completion event for the current 
partitioned application. ^ * ^ 

Objects representing all or part of partitioned applications 
may be stored in a user's R.S.400 if the objects meet certain 
criteria, such as being non-volatile, non-critical to network 
integrity, or if they are critical to ensuring reasonable re- 
sponse time. Such objects are either provided on diskettes 42 6 
together with R.S. system software used during the installation 
procedure or they are automatically requested by RS 4 00 when the 
user makes selections requiring objects not present in RS 400. 
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the latter case, RS 400 requests from cache concentrator layer 
only the 
application. 



3 00 only the objects necessary to execute the desired partitioned 



Reception system application software 42 6 is provided for 
most major brands of personal computers 405, and all partitioned 
applications are constructed according to a single architecture 
which each such RS 4 00 supports. Accordingly, R.S. 4 00 is 
independent of personal computer type and the operating system 
428 it may be using* With reference to FIG. 2, to access network 
10, a user preferably has a personal computer 4 05 with at least 
512K RAM and a single disk drive 416. The user typically access- 
es network 10 using a 1,200 or 2,400 bps modem (not shown). To 



m initiate a session with network 10, objects representing the 



logon application are retrieved from the user's personal disk- 
ette, including the R.S. application software, which was previ- 
ously set up during a standard installation - enrollment proce- 
dure (not explained f urther^) V? * Once communication between RS 400 
and cache concentrator layer 3CX0^h^fe ^een established, the user 
begins a standard logon procedure b^qT^iitting a personal entry 
code. Once the logon procedure is complete, the user can begin 
to access various desired services (i.e., partitioned applica- 
tions) providing the desired information display and/or transac- 
tion operations. 

APPLICATIONS AND PAGES 
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^ Applications, i.e. information events, are composed of a 
sequence of one or more pages opened at screen 414 of monitor 
412. This is better seen with reference to FIG 3 (a) and 3(b) 
W ere a page 255 is illustrated as might appear at screen 414 of 
monitor 412. With reference to FIG 3(a), each page 255 is 
formatted into page partitions 250, 260, 280, and 290 (not to be 
confused with applications partitions) . Window page partitions 
275 well known in the art are also available and are opened and 
closed conditionally on page 255 upon the occurrence of an event 
specified in the application being run each 250-290 and window 
275 is made up of a page element which define the content of the 
partition or window. 

Each page 255 includes :^a header page partition 2 50, which 
has a page element associated; with^ it and which typically conveys 
information on the page's topic or /sponsor; one or more body page 
partitions 260 and window page partitions 275, each of which is 
associated with a page element which as noted gives providing the 
information and transactional content of the page. For example, 
a page element may contain presentation data selected as a menu 
option in the previous page, and/or may contain prompts to which 
a user responds in pre-defined fields to execute transactions. 
As illustrated in FIG. 3(b), the page element associated with 
body page partition 260 includes display fields 270. A window 
page partition 275 represents the same informational and transac- 
tional capability as a body partition, except greater flexibility 
is provided for its location and size. 




£ Continuing with reference to FIG, 3(b), advertisements 280 
provided over network 10 like a page elements also include 
information displayed on page 255 may be included in any parti- 
tion of a page. Advertisements 2 55 may be presented to the user 
on an individual basis from queues of advertisements constructed 
off-line by business system 130, and sent to file server 205 
where they are accessible to each RS 400. 

Individual queues of advertisements are constructed based 
upon data collected on the partitioned applications that were 
accessed by a user, and upon events the user generated in re- 
sponse to applications. The data are collected and reported by 
RS 400 to a data collection co-application in file-server 205 for 
later transmission to business system 130. In addition to 
application access and use» : characteristics r a variety of other 
parameters, such as user demographics or postal ZIP code, may be 
used as targeting criteria. From such data, queues of advertise- 
ments are constructed and targeted tcPeither individual users or 
to sets of users who fall into certain groups according such 
parameters . 

Also with reference to FIG. 3b, a user interface 285 is 
displayed on the page, enabling the user to interact with the 
network RS 4 00 and the other elements of network 10 to cause 
such operations as navigating from page to page, performing a 
transaction, or obtaining more information about other applica- 
tions. As shown in FIG 3b, user interface 285 includes a command 
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290 having a number of commands 291-295 which the user can 
execute. The functions of commands 291-298 are discussed in 
greater detail below, interface, are discussed in greater detail 
below. 

NETWORK OBJECTS 

As noted above, in conventional time-sharing computer networks, 

the data and program instructions necessary to support user 

sessions are maintained at a central host computer. However, 

that approach has been found to create processing bottlenecks as 

p greater numbers of users are connected to the network; bottle- 
Si 

necks which require increases in processing power and complexity; 
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e.g.," multiple hosts of greater computing capability, if the 
network is to meet demand. Further, such bottlenecks have been 
found to also slow response,- time as more users are connected to 
the network and seek to have thei^r ^requests for data processing 



111 answered . *" /- // 



The consequences of the host processing bottlenecking is to 
either compel capital expenditures to expand host processing 
capability, or accept longer response times; i.e., a slower 
network, and risk user dissatisfaction. 

However, even in the case where additional computing power is 
added, and where response time is allowed to increase, eventually 
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host becomes user saturated as more and more users are sought 
to be served by the network. 

The method and apparatus of this invention are directed at 
alleviating the effects of host-centered limitations, and extend- 
ing the network saturation point. In accordance with the inven- 
tion, this is achieved by reducing the demand on the host for 
processing resources by structuring the network so that the 
higher network levels act primarily to maintain and supply data 
and programs to the. lower levels of the network, particularly RS 
400, which acts to manage and sustain the user screen displays. 

More particularly, the method aspect of the invention features 
procedures for parsing the network data and program instructions 

required to support the interactive user sessions into packets, 

• ' .** 

referred to as objects, and distrltiuting them into the network 

' - * / y 

where they can be processed at lower dej^s, particularly, 
reception system 4 00. 

In accordance with the invention, the screens presented at the 
user's monitor are each divided into addressable partitions shown 
in FIG. 3a, and the display text and graphics necessary to make 
up the partitions, as well as the program instructions and 
control data necessary to deliver and sustain the screens and 
partitions are formulated from precreated objects. Further, the 
objects are structured in accordance with an architecture that 
permits the displayed data to be relocatable on the screen, and 




be reusable to make up other screens and other sessions, 
either as precreated and stored sessions or interactive sessions, 
dynamically created in response to the user's requests. 

In accordance with the method aspect of the invention and as 
shown in FIG. 4c, the network objects are organized as a family of 
objects each of which perform a specific function in support of 
the interactive session. More particularly, the network object 
family is seen to include 6 members: page format objects 502, 
page element object 504, window objects 506, program objects 508, 
advertisement objects 5X0- and page template objects 500. 

Within this family, page format .objects 502 are designed to 
define the partitioning 250 to 290 of the monitor screen shown in 
Fig. 3a. The page format objects 502 provide a means for pre- 
defining screen partitions and for ensuring a uniform look to the 
page presented on the reception system monitor. They provide the 
origin; i.e., drawing points, and dimensions of each page parti- 
tion and different values for presentation commands such as 
palette and background color. 

Page format objects 502 are referenced whenever non-window data 
is to be displayed and as noted ensure a consistent presentation 
of the page. In addition, page format objects 502 assures proper 
tessellation or "tiling" of the displayed partitions. 
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^^p a ge element objects 504, on the other hand, are structured to 
contain the display data; i.e., text and graphic, to be displayed 
which is mapped within screen partitions 250 to 290, and to 
further provide the associated control data and programs. More 
specifically, the display data is described within the object as 
NAPLPS data, and includes, PDI , ASCII, Incremental Point and 
other display encoding schemes. Page element objects also 
control the functionality within the screen partition by means of 
field definition segments 516 and program call segments 532, as 
further described in connection with the description of such 
segments* Page element objects 504 are relocatable and may be 
reused by many pages. To enable the displayable data to be 
re-located, display data must be created by producers in the 
NAPLPS relative mode. 

Continuing with reference to FIG. 4c,. window objects 508 include 
the display and control data necessary to support window 
partitions 275 best seen in FIG. 3a. Windows contain display data 
which overlays the base page and control data which supersede the 
base page control data for the underlying screen during the 
duration of the window. Window objects 506 contain data which is 
to be displayed or otherwise presented to the viewer which is 
relatively independent from the rest of the page. Display data 
within windows overlays the base page until the window is closed. 
Logic associated with the window supersedes base page logic for 
the duration of the window. When a window is opened, the bit-map 
of the area covered by window is saved and most logic functions 
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r the overlaid page are de-activated. When the window is 
closed, the saved bit-map is swapped onto the screen, the logic 
functions associated with the window are disabled, and prior 
logic functions are reactivated. 

Windows are opened by user or program control. They do not 
form part of the base page. Windows would typically be opened as 
a result of the completion of events specified in program call 
segments 532. 

Window objects 506 are very similar in structure to page 
element objects 504. The critical difference is that window 
objects 506 specify their own size and absolute screen location 
by means of a partition definition segment 528. 

Program object 508 contain program instructions written in a 
high-level language called TRINTEX Basic/Object Language, i.e., 
TBOL, described in greater detail hereafter, which may be execut- 
ed on reception system 4 00 to support the application.. More 
particularly, program objects 508 includes interpretable program 
code, executable machine code and parameters to be acted upon in 
conjunction with the presentation of text and graphics to the 
reception system monitors. 

Program objects 508 may be called for execution by means of 
program call segments 532, which specify when a program is to be 
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^pecuted (event) , what program to execute (program pointer) , and 
how programs should run (parameters) . 

Programs are treated as objects to conform to the open-ended 
design philosophy of the DOA, allowing the dissemination of newly 
developed developed programs to be easily and economically 
performed. It is desirable to have as many of these program 
objects staged at or close to RS 400 as possible. 

Still further, advertising objects 510 include the text and 
graphics that may be presented at ad partition 280 presented on 
the monitor screen as shown in FIG. 3b. 

Finally, the object family includes page template objects 500. 
Page template objects 500 are designed to define the components 
of the full screen presented , to , the viewer. Particularly, page 

template objects 500 include the entr^y point to a screen, the 

< / 

name of the page format objects which<^ specif y the various 
partitions a screen will have and the page element object that 
contain the display data and partitioning parameters for the 
page. 

Additionally, page template object 500 includes the specific 
program calls required to execute the screens associated with the 
application being presented to the user, and may serve as the 
means for the user to selectively move through; i.e., navigate 
the pages of interest which are associated with various 
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applications. Thus, in effect, page template objects 500 
constitute the "recipe" for making up the collection of text and 
graphic information required to make the screens to be presented 
to the user. 

Also in accordance with the invention, object 500 to 510 shown 
in FIG. 4c are themselves made up of further sub-blocks of 
information that may be selectively collected to define the 
objects and resulting pages that ultimately constitute the 
application presented to the user in an interactive text and 
graphic session. 

More specifically and as shown schematically in FIG. 4a, objects 
500 to 510 are predefined, variable length records consisting of 
a fixed length header 551 and one or more self-defining record 
segments 552 a list of which. is presented in FIG. 4c as segment 
types 512 to 541. / 

In accordance with the invention, and as shown in FIG. 4b, 
object header 551 in preferred form is 18 bytes in length and 
contains a prescribed sequence of information which provides data 
regarding the object's identification, its anticipated use, 
association to other objects, its length and its version and 
currency. 

More particularly, each of the 18 bytes of object header 551 
are conventional hexadecimal, 8 bit bytes and are arranged in a 



^^.x pattern to facilitate interpretation by network 10. Particu 
larly, and as shown in FIG, 4b, the first byte of header 551; 
i.e., byte 1, identifies the length of the object ID in hexadeci 
mal. The next six bytes; i.e., bytes 2 to 7 , are allocated for 
identifying access control to the object so as to allow creation 
of closed user groups to whom the object (s) is to be provided. 
As will be appreciated by those skilled in the art, the ability 
to earmark objects in anticipation of user requests enables the 
network anticipate requests and pre-collect objects from large 
numbers of them maintained to render the network more efficient 
and reduce response time. The following 4 bytes of header 551; 
bytes 8 to 11, are used to identify the set of objects to which 
the subject object belongs. In this regard, it will be 
appreciated that, again" for speed of access and efficiency of 
selection, the objects are .arranged in groups or sets which are 
likely to be presented to user sequentially in presenting the 
page sets; i.e., screens that go to make up a session. 

Following identification of the object set, the next byte in 
header 551; i.e., byte 12, gives the location of the subject 
object in the set. As will be appreciated here also the identi- 
fication is provided to facilitates ease of object location and 
access among the many thousands of objects that are maintained 
to, thereby, render their selection and presentation more effi- 
cient and speedy. 
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Thereafter, the following bytes of header 551; i.e., byte 13, 
designates the object type; e.g., page format, page template, 
page element, etc. Following identification of the object type, 
two bytes; i.e., bytes 14, 15, are allocated to define the length 
of the object, which may be of what ever length is necessary to 
supply the data necessary, and thereby provides great flexibility 
for creation of the screens. Thereafter, a single byte; i.e., 
byte 16, is allocated to identify the storage characteristic for 
the object; i.e., the criterion which establishes at what level 
in network 10 the object will be stored, and the basis upon which 
it will be updated. At least a portion of this byte; i.e, the 
higher order nibble (first 4 bits reading from left to right) is 
associated with the last byte; i.e., byte 18, in the header which 
identifies the version of the object, a control used in determin- 
ing how often in a predetermined period of time the object will 
be updated by the network. 

Following storage characteristic byte 16, header 551 includes a 
byte; i.e., 17, which identifies the number of objects in the set 
to which the subject object belongs. Finally, and as noted 
above, header 551 includes a byte; i.e., 18, which identifies the 
version of the object. Particularly the object version is a 
number to establish the control for the update of the object that 
are resident at reception system 400. 
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As shown in FIG. 4a, and as noted above, in addition to header 
551, the object includes one more of the various segment types 
shown in FIG. 4c. 

Segments 512 to 541 are the basic building blocks of the 
objects. And, as in the case of the object, the segments are 
also self-defining. As will be appreciated by those skilled in 
the art, by making the segments self-defining, changes in the 
objects and their use in the network can be made without changing 
preexisting ob j ects . 

As in the case the objects, the segments have also been 
provided with a specific structure. Particularly, and as shown 
in FIG. 4a, segments 552 consists of a designation of segment 
type 553, identification of segment length 554, followed by the 
information necessary to -lipplement the segment and its associated 
object 555; e.g., either, control- data, display data or program 
code . " ^ / / 

In this structure, segment type 553 is identified with a 
one-byte hexadecimal code which describes the general function of 
the segment. Thereafter, segment length 554 is identified as a 
fixed two-byte long field which carries the segment length as a 
hexadecimal number in INTEL format; i.e., least significant byte 
first. Finally, data within segments may be identified either by 
position or key word, depending on the specific requirements of 
the segment. 



^^In this structure, segment type 553 is identified with a 
one-byte hexadecimal code which describes the general function of 
the segment. Thereafter, segment length 554 is identified as a 
fixed two-byte long field which carries the segment length as a 
hexadecimal number in INTEL format; i.e., least significant byte 
first. Finally, data within segments may be identified either by 
position or keyword, depending on the specific requirements of 
the segment. 



In accordance with the invention, the specific structure for 
the objects and segments shown in FIG. 4c would be as described 
P below. Object and segment structure is described, and segment 
yj function is briefly described. [ON NOTATION: the following 

description of the structure for objects and segments uses the 
following key conventions]: 



< > mandatory J 'item 

( ) optional item 

item may be repeated 



| item | | item j items in a column indicate either/or 

< > ( ) 
| item | | item | 
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OBJECTS 



PAGE TEMPLATE OBJECT: 



<header> 

<page format call> 
(program call) . . . 
(system table call) . 
(keyword/navigation) 



(compression descriptor) 
(page element call) . . . 
(page element selector) 
(external reference) 



Ui 

CO 
CO 



PAGE FORMAT OBJECT: 

<header> 

(page defaults) 



(compression descriptor) 
<partition def inition> 



PAGE ELEMENT OBJECT: 

<header> 

(presentation data) . . . 
(custom cursor) . . . 
(field definition) . . . 
(custom cursor type 2) . . 
(field definition type 2) 
( inventory control ) 



(compression descriptor) 

(program call) . . . 

(custom text) . . . 
(field level program call) . . . 
(custom graphic) . . . 

(array definition) . . . 
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^pNDOW OBJECT: 

<header> (compression description) parti- 

tion definition> (page element call) 

(presentation data) . . . (program call) . . . 

(custom cursor) . . . (custom text) . . . 

(custom cursor type 2) (custom graphic) 

(field definition)... (field level program call)... 

(field definition type 2)... (array definition).-. 

( inventory control ) 

PROGRAM OBJECTS: 

<header> (compression descriptor) <program data> ... 

SEGMENTS 

PROGRAM CALL SEGMENT 

Program call segments 532 are used to invoke programs. Program 
events will be specified in logical terms and will be mapped by 
the reception system native software 420 to specific physical 
triggers (e.g. , the "logical" event end-of-page may map to the 
physical <ENTER> key) . The logical event to be completed to 
initiate the program is specified in a one-byte token within the 



^^gment. The structure of program call segment 53 2 is as fol- 
lows: 

| prgm ob j . id | 
<st> <sl> <event> <pref ix> < > (parm) . . . 

| displacement | 

where "event" is a one-byte token of the logical event to be 
completed to initiate the program; "prefix" is a one-byte prefix 
to an object id or displacement; "object id" is id of the program 
object 506; "displacement" is a pointer to an imbedded program 
call segment 532; and "parm" is the parameters specific to the 
program. 

FIELD LEVEL PROGRAM CALL SEGMENTS 

Some programs, such as edits, must be triggered at the field 
level. Field-level program call segments 518 relate program 
calls to specified field definition segments 516. The structure 
of field-level program call segments is as follows: 

| prgm. obj . id | 

<st> <sl> <event> <f ield id> <pref ixx > (parm) . . . 

| displacment | 

where "event" is a one-byte token of the logical event to be 
completed to initiate the program; "field id" is the one-byte 
name of the field specified in a field definition segment 516 



^th which this call segment is associated; "prefix" is a one- 
byte prefix to an object id or displacement; "object id" is id of 
the program object 506; "displacement" is a pointer to an imbed- 
ded program call segment 532; and "parm" is the parameters 
specific to the program. 

PROGRAM DATA SEGMENT 

Program data segments 53 6 contain the actual program data to be 
processed by RS 400. Program data may include either source 
code, compiled machine code, macros, storage maps, and/or parame- 
ters. The structure of program data segments 536 is as follows: 

O 

ss 

W <st> <sl> <type> <program data> 

i 

Iff where "type" refers to the type of program data contained 
(l=TBOL, 2=table data). 

u s 

FU COMPRESSION DESCRIPTOR SEGMENT 

£S Compression descriptor segment contains information need for the 
decompression of objects compressed in interactive network 10. 
The segment is a formalization of parameters to be used by a 
decompression routine residing at the RS 400, using Huffman 
encoding well known the art. The structure of compression 
descriptor segment 538 is: 

<st> <sl> <table number> <length 1> (length 2) 
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^^tere "table number" is a one-byte number corresponding to the 

'class' indicator in the table structure segment of the 

appropriate decompression system table object; "length 1" is a 
two-byte indicator of the length of the segment after compression 
(not including object header and length of compression descrip- 
tor) ; and "length 2" is a two-byte indicator of the length of the 
segment before compression (not including object header and 
length of compression descriptor) . 

PAGE DEFAULT SEGMENTS 

Page default segments 540 specify defaults for the entire page 

O using NAPLPS commands. The structure of page default segment 54 0 
M 

yj 

w ' - 

U <st> <sl> <NAPLPS> 

P PARTITION DEFINITION SEGMENT 

M 

nj Partition definition segment 528 describes display screen areas 
08 

into which data may be mapped. The structure of partition 

y3 

definition segment 528 is: 

<st> <sl> <partition id> <origin> <size> (NAPLPS) 

where "partition id" is a one-byte partition id unique within the 
current page format object 502; "origin" is the partition origin 
point, a three-byte NAPLPS point set (absolute, invisible) 
operand contained the absolute coordinates of the lower left 
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^prner of the partition; and "size" refers to partition size, a 
three-byte NAPLPS point set (absolute, invisible) operand con- 
taining the absolute coordinates of the upper right corner of the 
partition. 



PAGE FORMAT CALL SEGMENT 

Page format call segment 526 is used by the page template object 
500 to specify the particular page format object 502 to be used 
as the "blueprint" of the page. Page format call segment 52 6 
structure is as follows: 



£3 <st> <sl> <prefix> <object id> 

M 
n - s- 

gj where "prefix" is a one-byte prefix to an object id or displace- 
l n ment; and "object id" is the object id of the page format object 

502 . ' - , - 



PAGE ELEMENT CALL SEGMENT 



jjjj Page element call segment 522 specifies which data is to be 

present on the base page and in which page partition the data is 
to appear. The structure of page element call segment is as 
follows : 



| object id | 

<st> <sl> <partition id> <priority> <prefix> < > 

| displcmnt | 
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^piere "partition id" is the partition id, as specified in the 
page format object 502 upon which this object will act; "priori- 
ty" is a one-byte binary flag indicating priority (from 0-15 with 
0 indicating no priority [FIFO}) of object interpretation (high- 
order nibble) and of painting (low-order nibble) ; "prefix" is a 
one-byte object id or displacement; "object id" is the id of the 
page element object 522; and "displacement" is a pointer to an 
imbedded page element object 52 2. 

PAGE ELEMENT SEUECTOR SEGMENT 

Page element selector segment 524 provides a mechanism by which 
□ page elements may be dynamically selected for presentation within 
a partition. The structure of page element selector segment 524 
is: 



| pgm. ob j . id | 

<st> <sl> <part.id> <priority> <prefix> < >(parm) 

| displacement | 
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where "part, id" is the partition id as specified within the page 
format object 502 upon which the object will act; "priority" is a 
one-byte binary flag indicating priority (from 0-15 with 0 
indicating no priority [FIFO)) of object interpretation (high- 
order nibble) and of painting (low-order nibble) ; "prefix" is a 
one-byte object id or displacement; "pgm . obj . id" is the object id 
of the program object 508 used to dynamically select an element 
object; "displacement 11 is a pointer to an imbedded program object 
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^^08, and "parm" is parameters which are used by the program 
object 508. 

SYSTEM TABLE CALL SEGMENT 

System table call segments 542 call system table segments for use 
by the RS 400. Each table entry in a system table segment 
contains an index-addressable segment (e. g. , a set of custom text 
segments 514) . System table call segments operate in a "locked- 
shift" mode, meaning that each system table of a particular class 
will remain operative until a new table is requested for that 
class of table. System table call segment 542 structure is as 
follows : 

[object id| c \ 
<st> <sl> <prefix> < > 

| displcmnt | 

where "prefix" is a one-byte prefix to an object id or displace- 
ment; "object id" is the id of a system table segment; and 
"displacement" is a pointer to an inbedded system table segment. 

TABLE STRUCTURE SEGMENT 

Table structure segments 554 describe the basic class and compo- 
sition of system table objects. The structure of table structure 
segment 554 is: 

<st> <sl> <class> <number of entries> <maximum entry length> 
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^ere "class" is a one-byte identifier indicating the class of 
the current table (as follows: 



x'00' = custom text table 

x'01' = custom cursor table 

x'02' = custom graphic table 

x'03' = custom cursor type 2 table 

x'30' thru x'39' = decompression table); 

"number of entries is a two-byte field specifying the total 
number of entries contained in the current table; and "maximum 

P entry length" is a two-byte field specifying the length of the 

juj largest entry in the current table. 



Iff 



TABLE ENTRY SEGMENT 

Table entry segment 556 contains the actual data that has been 

O placed in tabular form. The meaning of the data is derived from 

M 

"5s 

ftj the class indicator in the table structure segment 554 . They 



m 



will be treated as functional equivalent of certain other seg- 
ments such as custom text segment 514 or custom cursor segment 
512. Table entry segment structure is: 

<st> <sl> <data> 



where "data" is the data contained in the entry (text character 
attributes if table belongs to the custom text class; NAPLPS if 
the table belongs to the custom cursor class) . 
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^^TERNAL REFERENCE SEGMENT 
External reference segment 544 is provided to improve run-time 
performance by providing the RS 400 with a list of objects that 
are candidates for pre-f etching. External reference segments 54 4 
contain a list of object ids which are used within the current 
page. Each object indicated within this list is called explicit- 
ly from the current frame. Object ids specified within the 
external reference segment 544 will take advantage of the notion 
of "inheritance." If multiple object ids are contained within 
the segment, they may inherit high-order bytes from previously 
specified ids, thus avoiding repetition of information that is 
inherited (e.g. to specify objects ABC12 , ABC2 2 , and ABC37 in 
this segment, one encodes them as ABC12 , 22, 37). External 



reference segments 544 operate in a "locked-shif t" mode, meaning 

fZ that each external references / list will be active until the next 

Lfi 

0 1 external reference list is encountered. In the best mode, there 

53 

should be no more than one external reference segment per page. 
External reference segment structure is as follows: 

<st> <sl> <# of ids> <priority> <prefix> <object id> 



Si 
fa 
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where "# of ids" is a one-byte field specifying the total number 
of object ids contained in the current segment; "priority" is a 
one-byte priority value specifying priority of pre-fetch (priori- 
ties may be duplicated, in which case they will be processed from 
left to right) ; "prefix" is a one-byte prefix to an object id or 
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^splacement; and "object id" is the id of an externally refer- 
enced object. 

KEYWORD/NAVIGATION SEGMENT 

Keyword/navigation segments 520 may contain two types of informa- 
tion: (1) references to other page template objects 500 that are 
either logically higher than the current page template (e.g., a 
"parent" menu) or references to page template objects 500 outside 
the current "world" (a logically cohesive group of pages having a 
single entry point, such as a general map of the interactive 
service) ; or (2) a character string to be associated with the 
current page template object 500, which may be displayed to the 
user to indicate an alternative path or keyword which could be 
used to access the current page template. The structure of 
keyword/navigation segment is as follows 

<st> <sl> <#ids> (<prefix> <object id>) ... (character string) 

where "#ids" is the number of object ids in this segment; "pre- 
fix" is a one-byte object id prefix; "object id" is an object id 
associate witha the current page as either an upward hierarchical 
reference or a non-hierarchical reference; and "character string" 
is the character string to be associated with the current page. 
(See also, discussion of JUMPword navigation, below) . 

PRESENTATION DATA SEGMENT 
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esentation data segments 53 0 contain the actual contain the 
actual data to be displayed or otherwise presented to the user. 
Presentation data may contain NAPLPS codes, ASCII, and other 
codes for visual display. Presentation data may in the future 
contain codes for the presentation of audio signals. The struc- 
ture of presentation data segment is: 

<st> <sl> <type> <size> presentation data> 

where "type" is the type of presentation data included in this 
segment (1=NAPLPS, 2=ASCII) ; "size" is a NAPLPS operand that 
defines the upper right portion of the display data; and "presen- 
tation data" is the actual data to be presented to the user. 

FIELD DEFINITION SEGMENT 

Field definition segments 516 define the location of a field, 



C? name the field, and specify how data will be acted on within the 



FU named field. Field definition segment 516 structure is as 
g3 follows: 



<st> <sl> <attributes> <origin> <size> <name> 
<text id> (cursor id) (cursor origin) 



where the structure is defined as below. 



"Attributes" of a field define ways in which the user interacts 
with RS 400 at a rudimentary level. Three basic field types are 
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^^jpported: (1) unprotected fields into which users may enter 
data; (2) protected fields into which users may position the 
cursor, function and enter keys, but may not enter data; and (3) 
skip fields which are inaccessible to the user keyboard. Addi- 
tional attributes which may be specified for a field include: 
numeric input only (unprotected) ; alphabetic input only (unpro- 
tected) ; foreground color; and background color. Attributes are 
encoded in two bytes. The first nibble of the first byte is a 
hexadecimal number (O - F) that represents the foreground color 
selection from the in-use palette. The second nibble of the 
first byte is a hexadecimal number (O - F) that represents the 
O background color selection from the in-use palette. The first 
nibble of the second byte consists of a set of bit flags which, 
^ from left to right, indicate: 

Us 

w bit 0 if '1' : protect on 

O bit 1 if '1' : automatic skip on 

FU bit 2 if : numeric input only -■ 

EI bit 3 if : alphabetic input only. 

The second nibble of the second byte is reserved for future 
expansion. 

"Origin" is a three-byte NAPLPS point set (relative, invisible) 
operand that defines the lower left corner of the field. 



SI 
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^^ize" is a three-byte NAPLPS point set (relative, invisible) 
operand that defines the upper right corner of the field . 

"Name" is a one-byte name assigned to the field so that it may be 
accessible to programs. 

"Text id" is a one-byte id of the text characteristics to be 
associated with the field (e.g., size, gapping, proportional 
spacing, etc . ) . 

"Cursor id" is a one-byte id of the cursor type to be associated 
O with the field. 

SI 
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m "Cursor origin" is a three-byte NAPLPS operand specifying rela- 



in 
m 



tive draw point to the cursor. If this operand is not present, 
the cursor origin point will be assumedn to be the same as the 



^ field origin point. 

ry 

Gtl FIELD DEFINITION TYPE 2 SEGMENT Field definition type 2 segments 

Tfc? 

548 are provided to enhance run-time flexibility of fields. 
Field definition type 2 segment structure is as follows: 



<st> <sl> <attributes> <origin> <size> <name> 
<text id> <cc 11> (<cursor id> (cursor origin) ) 
<# hot spots> (<hs 11> <hssize> (hsorigin) ) . . . 
(<cg 11> <cgraphic id> <cgmode> (cgorigin) ) . . . 
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sphere structure is defined below. 

"Attributes" of a field describe how the user and RS 4 00 interact 
at a rudimentary level. Attributes for field definition type 2 
segments 548 are contained in four bytes: 



Byte 1 Field type 

bit 0 TBOL interpreter indicator 

'0' no fire 
'0' fire 

bits 1-7 Interaction type 

x'000 0000 : input (unprotected) 
x'000 0001 : action (protected) 
x'000 0010 : display (askip) 
x'000 0100 : hidden (dark) Byte Byte 



2 Text Attributes (bit flags) 

bits 0-7 x'0000 0001 : left justify 

x'0000 0010 : right justify 
x'0000 0100 : word wrap Byte Byte 

3 Data Type 

bits 0-7 x'0000 0001 : alphabetic 

x'0000 0010 : numeric 

x'0000 0100 : password Byte Byte 

4 Color 

bits 0-3 foreground color 

bits 4-7 background color 



j^Origin" is a three-byte NAPLPS point set (relative, invisible) 
operand that defines the lower left corner of the field. 

"Size is a three-byte NAPLPS point set (relative, invisible) 
operand that defines the upper right corner of the field. 

"Name" is a one-byte name assigned to the field so that it maybe 
accessible to the program. 

"Text id" is a one-byte id of the text characteristics to be 
associated with the field, such as size, gapping, proportional, 
etc . 



"cc 11" is the cursor length; a one-byte field describing the 

jhjl combined length of the cursor id field and the cursor origin 

y s 

w ' ? field. If the length contains a 1, then the cursor origin 

O operand is not present, in which case, the cursor origin defaults 

M 

fU to the field origin point. 

"J3 

"Cursor id" is a one-byte id of the cursor type to be associated 
with the field. 

"Cursor origin" is a three-byte NAPLPS operand specifying the 
relative draw point of the cursor. If this operand is not 
present, the cursor origin point will be assumed to be the same 
as the field origin point. 
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hot spots" is the number of hot spots used by this field. 
"Hot spots" fefers to a set of coordinates that will be select- 
able by a pointing device, such as a mouse. If the contents of 
this field are zero, the hot spot for the field will be assumed 
to be the coordinates that are covered by the custom cursor. 

"Hot spot sets" facilitate assigning a variable number of hot 
spots to a field. Each hot spot is described by a set of oper- 
ands consisting of hot spot length, origin, and size. Each set 
of such operands describes one hot spot. When using multiple hot 
spots, multiple sets of operands must be present. 

"hs 11" or hot spot length is a one-byte binary field describing 
the length of the hot spot coordinates for a hot spot "instance." 
If this byte contains zero', the hot spot origin and size default 
to the coordinates described by the custom cursor. If this byte 
contains 3, then the hot spot origin point will not follow, but 
will default to the custom cursor origin point. If this byte 
contains 6, then both the hot spot origin and size are present. 

"Hot spot size" is a three-byte NAPLPS x,y coordinate describing 
the top right corner of the hot spot. 

"Hot spot origin" is a three-byte NAPLPS x,y coordinate describ- 
ing the lower left corner of the hot spot. If the hot spot lenth 
is equal to 3, this field is not present. In that case, the hot 
spot origin point defaults to the origin point of the custom 




^pirsor (which may have also defaulted to the field origin point) . 
If the hot spot lenth is equal to 6, then this field is present. 

A custom graphic operand set contains four operands: 

"eg 11" or custom graphic set length, which, if 2, then no 
custom graphic origin is present. In that case, the origin 
point of the custom graphic defaults to the field origin point; 

"eg id" or custom graphic id, a one-byte identifier of a custom 
graphic string; 

"cgmode" or custom graphic mode, which is one byte used to 
describe variable conditions that apply to the graphic. 
Defined values include: 

x' 01 : blink 
x'02 : dynamic 
x'03 : permanent 

"cgorigin" or custom graphic origin, a three-byte NAPLPS x,y 
coordinate indicating the lower left corner of the custom 
graphic. If this operand is not present, the lower left corner 
will default to the field origin point. 

ARRAY DEFINITION SEGMENT 
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^^ray definition segments 548 define the names and relative 
locations of fields in a row that makes up an array or table. 
The first row of fields must have been defined using field 
definition segments 516. The array definition provides a short- 
hand for specifying the replication of selected fields from the 
initial page. The structure of the array definition segment 548 
is as follows: 

<st> <sl> <#occurrences> <vertical gap> <f ield name> . . . 

where " ^occurrences" is a one-byte field describing the number of 
rows to be generated to create the array (the first row is 
assumed to be generated from field definition segments 516) ; 
"vertical gap" is a NAPLPS point /se.t operand (relative, invisi- 
ble) containing the DY of inter-row spacing; and "field name" is 
a one-byte name (from the field definition) of the fields in a 
row of the array. CUSTOM GRAPHICS SEGMENT 

Custom graphics segment 550 provides a means to package graphics 
commands. These graphics commands may be related to a field and 
initiated based on run-time conditions. The structure of custom 
graphics segment 550 is as follows: 

<st> <sl> <id> <size> <NAPLPS> 

where "id" is a one-byte identifier for this custom graphic; 
"size" is a three-byte NAPLPS operand specifying upper right 
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^prner of the graphic area in a relative mode; and "NAPLPS" are 
NAPLPS commands to paint the custom image. 

CUSTOM CURSOR SEGMENT 

Custom cursor segment 512 allows fancy graphics to be associated 
with cursor positioning in a field. Using this segment, cursors 
may be defined to any size or shape and may be placed at any 
desired location relative to their associated fields. The 
structure of custom cursor segment 512 is as follows: 

<st> <sl> <id> <size> <NAPLPS> 

where "id" is a one-byte identifier for this custom cursor; 
"size" is a three-byte NAP3>P;S operand specifying upper right 
corner of the cursor area in a relative mode; and "NAPLPS" are 
NAPLPS commands to paint the custom image. 

CUSTOM CURSOR TYPE 2 

Custom cursor type 2 segment 552 allows cursors to be defined to 
any size or shape and may be placed at any desired location 
relative to their associated fields. The structure of custom 
cursor type 2 segment 552 is as follows: 

<st> <sl> <id> <size> (<11> <NAPLPS>) . . . 

where "id" is a one-byte identifier for this custom cursor; 
"size" is a three-byte NAPLPS operand specifying upper right 



^^>rner of the cursor area in a relative mode; "11" is the length 
of the following NAPLPS data; and "NAPLPS" are NAPLPS commands to 
paint the custom image. 

CUSTOM TEXT SEGMENT 

Custom text segments 514 allow the definition of custom display^ 
of text within a field when non-standard character field size is 
used (20 x 40 display characters is standard) or custom spacing, 
movement, or rotation of characters is desired. The structure of 
custom text segments 514 is as follows: 

<st> <sl> <id> <NAPLPS> 

where "id" is a one-byte identifier for this TXT command; and 
"NAPLPS" are NAPLPS commands specifying character field size, 
rotation, movement, inter-row and inter-character text gaps. 

INVENTORY CONTROL SEGMENT 

Inventory control segment is provided to facilitate management of 
objects. The inventory segment is structured: 

<st> <sl> <type> <inventory number> (sub-number) 

where type is a one-byte indicator showing object usage (as 
follows: 

0 = no defined use 
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1 = leader ad 

2 = ad campaign completion 

3 = leader ad completion 

4 - 255 = reserved for future use) ; 

"inventory number" is a unique two-byte number to be used for 
inventory control and statistics; and "sub-number is the same as 
inventory number. 

At Page 27, Line 24, is inserted the following: 

NETWORK MESSAGES 



In addition to the network objects and the display and control 
data, and the program instructions previously they contain as 
*H described, network 10 also exchanges information regarding the 

O support of user sessions and the maintenance of the network as 

Si 

fy "messenger". Specifically, the messages typically relates to the 
exchange of information associated with initial logon of a 
reception system 400 to network 10, dialogue between reception 
system 4 00 and other elements and communications by the other 
elements amongst themselves. 

In accordance with the invention, to facilitate message 
exchange internally, and through gateway 210 to entities exter- 
nally to network 10, a protocol termed the "Data Interchange 
Architecture" (DIA) is used to support the transport and 
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^terpretation of information. More particularly, DIA enables: 
communications between RS 400 units, separation of functions 
between network layers 100, 200, 300 and 401; consistent parsing 
of data; an "open" architecture for network 10; downward compati- 
bility within the network, compatibility with standard industry 
protocols such as the IBM System Network Architecture and Open 
Systems. Interconnections Standard; support of network utility 
sessions and standardization of common network and application 
return codes . 

Thus DIA binds the various components of network 10 into a 
coherent entity by providing a common data stream for communica- 
tions management purposes. DIA provides the ability to route 
messages between applications based in IBM System Network Archi- 
tecture (SNA) , (well known in the art, and more fully described 
in Data and Computer Communications, by W. Stallings, Chapter 12, 
McMillian Publishing, Inc. (1985) ) and non-SNA reception system 
applications; e.g. home computer applications. Further, DIA 



provides common data structure between appl-ications run at RS 4 00 



units and applications that may be run on external computer 
networks; e.g. Dow Jones Services, accessed through gateway 210. 
As well, DIA provides support for utility sessions between 
backbone applications run within network 10. 



In make up, DIA is a blend of SNA and Non-SNA based modes, and 
thus provides a means for combining the differences between these 
modes within network 10. Accordingly, the action of DIA differs 
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^^pending on whether DIA is operating within an SNA portion of 
network 10 or whether it is operating within the non-SNA portion 
of the network. More specifically, within the SNA portion of 
network 10, DIA and its supporting programs may be considered 
"applications" facilities. In this context, DIA resides at the 
transaction services level of SNA, also known as the Specific 
Application level of Open Systems Interconnections (also 
discussed in chapter 12 of Data and Computer Communications by W. 
Stall ings above noted) . However, in either case, it is a level 7 
facility . 

Within non-SNA portions of network 10, DIA and its supporting 
programs provide routing, transport, sessions, and some 
transaction facilities- Thus DIA provides a comprehensive 
network architecture providing OSI level 3, 4, 5 and 7 services. 

In accordance with the invention, DIA facilitates "utility 
session" within network 10. Utility sessions allow partner 
applications to communicate by means of the single session 
established between two logical units of the SNA type. In order 
to reduce the number of resources which must be defined to the 
network support programs, many user messages may be passed to 
many different application destinations through logical unit to 
logical unit (LU-LU) "pipes". 

Applications exist on either side of the LU-LU pipe which act 
to concentrate outbound messages en route to applications 
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^pisident on the other side of the LU-LU pipe; distribute inbound 
messages to local applications; and maintain and manage applica- 
tion task boundaries. Users may enter into a conversation with a 
set of transactions, refined to tasks, which are hereafter noted 
as "user sessions", and the boundaries of these user sessions 
(tasks) are indicated by begin session/ end session flags. 

Another application function supported by DIA is the routing of 
messages between nodes of network 10. Particularly, a switching 
application will route messages to the appropriate LU-LU session 
for transmission to another mode by examining and resolving the 
DIA destination IDs hereafter described. 

In accordance with the invention messages conforming to DIA are 
composed of two functional parts: message headers and message 
text. Message Headers are transparent to most applications, but 
are the primary vehicle for passing information for session-layer 
to session-layer or transport-layer to transport-layer communica- 
tions. Further, Message Text which is processed by end-users, 
and is transparent to session and transport mechanisms. 

In order to reduce program complexity and facilitate mainte- 
nance and enhancements, DIA has been structured in a layered 
fashion. In this regard, the DIA-defined data which flows 
through network 10 consists of a set a headers preface the 
end-user to end-user message text. Further, as in the case of 
objects, messages are organized in a family of types based on the 
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^p>ecific form of its header. Particularly, there are "FMO M 
headers which contain routing and control information; FM2 
headers which contain transport level information; FM4 headers 
which contain gateway information; FM8 headers which obtain 
information for secondary routing; i.e. messages passed through 
from node to node; FM9 headers which contain network management 
information; and FM64 headers which contain application-to-appli- 
cation management information, where, for example, applications 
running at RS 4 00 need be rendered compatible with applications 
running on an external computer connected to network 10 through a 
gateway 210 . 

In order to provide SNA compatibility, the first two bytes of 
all DIA FM headers are formatted such that byte 1 defines the 
length of header in hexadecimal; and byte 2, bit 0, identifies 
whether concatenation is provided or not; e.g. if bit 1 = 0 no 
other headers follow, but if bit 1 = 1, then the current header 
is followed by a concatenated header; while bits 1 -7 identify 
the header type in hexadecimal value. 

As will be appreciated to those skilled in the art, this layout 
is the same as that of SNA Function Management Headers. In an 
SNA LU0 implementation the DIA FM headers may be treated as SNA 
Function Management Headers (FMHs) . Alternatively, the DIA FMs 
may be treated as pure data within the SNA Request Unit (RU) . 
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^^With regard to destination routing, the basic premise of DIA is 
that each message flowing through network 10 carries a DIA header 
( FMO ) that identifies its source and destination ids. 
Accordingly, switching applications exist which map destination 
ids to resources and route messages appropriately. In accordance 
with the invention, in order to send a reply, the recipient 
application simply swaps the content of the destination and 
source id fields and return message. 

In the context of DIA the totality of ports, devices, and 
programs which are managed by a particular Switch and defined as 
destinations, are referred to as "regions". In this regard, each 
Switch; i.e. server 2 05 or cache/concentrator 3 02 shown in Fig. 
2, need only be aware of the destination ids of resources within 
its own region and of the destination ids of switches resident in 
immediately adjacent nodes. Since server 205 is the central hub 
within the network 10 for application message routing, messages 
destined for end-users unknown to a switch are routed toward 
server 205 for eventual resolution. Destination id naming 
conventions then enable server 2 05 to determine the appropriate 
switch to which the message should be forwarded. Particularly, 
"destination id" fields "regions" and "unit" are used for this 
purpose . 

Concerning switch responsibility, a switching application has 
three primary responsibilities. It must forward messages to 
adjacent switches. It must collect messages from, and distribute 
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^^ssages to resources within its own region. And, it must 
maintain and manage application task boundaries. Users may enter 
into a conversation with a set of transactions. This set of 
transactions is referred to as a "task". These tasks are called 
user sessions. Further, the boundaries of these tasks are 
indicated by begin session/end session flags. 

In order to fulfill these functions, a resource definition 
facility must exist for each switch to map each addressable 
resource to a destination id. In some cases, particularly on the 
RS 400, it may be desireable for an application to dynamically 
define subordinate resources to the switch and to interact with 
the switch to generate unique destination ids for these subordi- 
nate resources. It may also be necessary for the switch to 
either communicate with, or act within an application subsystem; 
An example of an application subsystem is the Customer Informa- 
tion Control System, (CICS) event, where CICS is a commercially 
available transaction process controller ,of the IBM Company, well 
known in the art. CICS, although subordinate to the operating 
system, is responsible for initiating and managing application 
"transaction" programs. Routing to specific transactions under 
the control of an application subsystem may be accomplished by a 
secondary address. In this case, the subsystem is defined as the 
primary destination. The transaction is defined as the secondary 
destination. A switch must only route incoming messages to the 
subsystem. The subsystem in turn posts to, or initiates the 
desired transaction . 



^^The use of secondary addressing provides several advantages. 
Particularly, switch resource tables are not affected by the 
coming and going of "transaction" applications. Further, since 
the DIA headers are SNA compatible, Type 1 application such as 
CICS need have no special message routing functions. A switch 
configured in accordance with the IBM standard VTAM could route 
incoming messages to CICS. Still further, transactions need not 
go into "receive loops". It is possible for the subsystem to 
poll on behalf of many transaction programs. In accordance with 
DIA, secondary addressing is implemented within the application 
data stream. For instance, CICS transaction ids are, by conven- 
tion, to be found in the first four bytes of application text. 

With regard to the standards for DIA, it will be recalled that 
DIA messages have a header followed by the message information. 
In the preferred embodiment, the DIA headers may be concatenated 
to one another. Further, the presence of concatenated headers is 
indicated by the setting of the first bit (bit 0) of the Header 
Type field. 

However, there are two restrictions on the use of concatenated 
headers. Particularly, concatenated headers are required to be 
sequenced in ascending order left to right by header type numbers 
and secondary message text prefaced by concatenated headers (such 
as FM64 architectured message text) are not permitted to span 
across message block. 
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^^The basic structure of all DIA headers is presented below. As 
presented "o" indicate mandatory elements, " ( ) 11 indicate 
optional elements an " . . . " indicate repeat allowed. Further, the 
"FMX" designations refer to the message header types previously 
identified and "TTX denotes. (<Length> Concatenation flag> 
<Type> (FM defined data) ) . 

For TTX application-to-application message the structure is: 
(<FMO> (FM2) (FM8) (<FM64> (64text) )' . • . (Appl - Text)). 

For TTX application-to-gateway application messages the 
structure is: (<FMO> (FM2) (FM4) (FM8) (<FM64> (64text))... 
(Appl . Text) ) . 

For TTX message to TTX network management, the structure is: 
(<FMO> «FM9> (9text)> ). 

Finally, for internal TTX Switch to Switch messages, the 
header structure is: (<FMO> (Appl. Text) ), where the FMO func- 
tion code is 2x or Cx. 

Continuing, the general rules of implementation for DIA 
messages in the preferred embodiment are as follows. All inter- 
network messages are prefaced by a single FMO. Further, other 
header types can be optionally concatenated to the FMO. Also, 
headers should occur in ascending order by header type; i.e. FMO, 
FM2, FM4, FM8, FM9 , FM64 . Header and text length values are 



^rried as binary values. Numeric fields contained within DIA 
headers are carried with the most significant values in the 
left-most byte(s) . 

Further, long gateway messages (greater than IK bytes including 
headers) are sliced up into blocks. This segmentation is 
indicated by the presence of the FM2 Header. In the preferred 
embodiment, the current block number of the FM2 must be correctly 
set because it acts as a sequence number and provides a means to 
guarantee message integrity. In this regard, the total number of 
blocks field must be set correctly when sending the last block of 

q a logical message. Receiving programs can determine end-of- 

C] 

i 2 "h message by testing block number = total number blocks. If the 
sender cannot pre-determine the total number of blocks m a 



•ass. 
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beginning or middle of message block, the sender must place 
binary zeros in the total number of blocks field. 

Still further, in the preferred embodiment, FM9 architected 
text may not span message blocks and may not be longer than 255 
bytes. Additionally, FM64 architected text may not span message 
blocks and may not be longer than 512 bytes long. Yet further, 
only a single instance of FM2 and/or FM4 can be present in a 
message block. And, messages using FM9 or FM64 headers must be 
less than IK bytes, and these messages should not be segmented 
into blocks. 
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Continuing with the DIA implementation rules, FMO and FM2 must 
be present in each block of a multi-block message when being 
transported within the network system. Normal application 
message flow consists of a request/response pair. In normal 
processing, reception system applications send requests to host 
applications. Host applications return responses to these re- 
quests. The Reception System application initiates this dialogue. 
Sending nodes are responsible for inserting the proper "source 
id" (SID) and "destination id" (DID) into the FMO. Additionally, 
the communications manager (CM) of the reception system further 
described hereafter, acts on behalf of reception system transac- 
tion programs. Messages destined to the CM should be considered 
systems messages (FMO FUNCTION = Cn) . Messages destined to 
subordinate transactions on reception system 4 00 should be 
considered applications message (FMO Function=0n) . Receiving 
nodes are responsible for swapping SID and DID contents when 
returning a response. Still further, intermediate nodes (with 
the exception of . CICS switches and Gateways) need only be aware 
of FMO and FM2 headers when routing messages to other destina- 
tions. CICS switches must be cognizant of all header layouts so 
that they can find the displacement to the transaction id which 
is contained within the first four bytes of application text. 
And server switch 205 provides a facility which allows responses 
to requests to be deliverable for at least a minimum period after 
the request was sent, e.g. , one minute. 



^Finally, the preferred embodiment, CICS switches pass all DIA 
FM headers on to their subordinate applications. The applications 
are then responsible for returning the headers (with the SID/DID 
swap) back to the switch for responses. Both fixed length and 
variable length message headers are supported by the DIA. It must 
be noted that variable length headers are designed so that only 
the last field within the header is variable in length. 

With regard to mode of conversation under utility sessions, the 
server switch 2 05 may engage in multiple sessions with an 
external CICS. Messages originating from network users may be 
routed through any of these sessions. Users are not forced to 
I„j use the same utility session pipe for each; message outbound to 

CICS. Pipes may be selected dynamically based on loading factors. 
In a switch-driven environment CICS transactions may typically be 
P initiated by means of start commands from the switch. In this 
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Q arrangement, CICS transactions will pass outbound data back to 
fy the switch through a queue. 



In accordance with DIA, the potentially dynamic nature of 
conversation routing dictates that CICS transaction programs not 
be written in a conversational mode. Rather, the transaction 
programs are preferably either pseudo-conversational or non- 
conversational. In this regard it should be noted that conversa- 
tional transactions send a message and wait for a reply, and 
non-conversational transactions send a message and expect no 
reply. In the case of pseudo-conversational transactions, a 
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psage is sent, but no reply is expected. However, such messag- 
es are coded so as to be able to accept user input in various 
stages of completion, thus mimicking conversational transactions. 

As will be appreciated by those skilled in the art, communi- 
cations may arise within network 10 that do not require the 
standards applied to DIA messages. However, non-DIA messages are 
allowed in the DIA structure. Particularly, non_DIA messages are 
designated by setting the length portion of the header (i.e., the 
first byte) to binary zero. 

Considering header layout, and with input first to FMO headers, 
it should be noted that the FMO header provides routing 
information to both intermediate and boundary switches. In 
lZ addition the FMO contains control fields which allow the sending 
application (which may be a switch) to communicate information to 
the switch which "owns" the destination application. When an 
originating application wishes to converse with an application 
resident on the other side of an utility session it must initial- 
ly pass an FMO header with a function code representing an 
"begin session" to its controlling switch. The begin session 
code requests the assistance of any intervening switches in the 
establishment of an application session between the requestor and 
the destination application specified in the DID. 



When either application session partner wishes to terminate its 
conversation the session partner must pass an FMO header to its 
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^pritch, specifying either a function code representing an "end 
session", or "end session abnormal", or "request terminate". 
These function codes request the assistance of any intervening 
switches in the termination of the application session between 
the requestor and the destination application specified in the 
DID. In this arrangement an end session function code is uncondi- 
tional and does not require an acknowledgment. An end session 
abnormal function code is unconditional and does not require an 
acknowledgment. And, a request terminate function code is 
conditional and requires a positive acknowledgement. The posi- 
tive acknowledgement to a request terminate is an end session. 
The negative acknowledgement to a request terminate is a function 
code representing "status Message". 

Further, "status/return" function codes "system up", "system 
down", "echo", "system message" are used by corresponding appli- 
cations in different regions of network 10 to determine applica- 
tion availability and user session status. Function codes are 
also used to designate end-to-end user message classes of ser- 
vice. These classes of service refer to a delivery requirement 
classification and are distinguished from SNA COS. Network class 
of service allows applications to specify whether or not respons- 
es to requests can be delivered after the standard timeout of 
server 205 has occurred. 

In accordance with the invention, the DIA headers are arranged 
in a predetermined form base on their function. More 
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^^rticularly , FMO headers, also known as Type "O" headers are 
required for every message within the network . Header Type 0 
provides information necessary for routing and message correla- 
tion. Its fields include: 



Header Length - Length of header data including length 
field. Header Type - Bit 0 is header concatenation flag. 

Bits 1-7 indicate current header type. 
Function Code - Contains message function. Data Mode 
Indicates attributes of message data. 

The "response expected" bit should be turned 
off if no response is expected, for instance, 
when sending the response to a request. Source 
Id - Identification of end-user sending current 

message. Logon Sequence Number - number 

which in conjunction with source id 
O provides unique identification of source 

pj when source is reception system. Message 

OP 

flg Sequence Number - used to correlate requests and 

responses. Destination Id - Identification of message 
destination. 

All messages are routed by destination id. 
When responses to messages are sent back to 
original source, the source id and destination 
ID fields must be swapped. Text Length - length 
of all remaining data in the message to 

the right of this fields. (Includes length of 
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concatenated headers if any are present) - 
The layout for the Type O header is as follows: Header Type 0 



layout: Byte 0 
Header Type 
bit 0 

bits 1-7 
i.e. 



Header Length (hexadecimal) Byte 1 

if '0' no other headers present 
if '1' concatenated header present 
000 0000 Byte 2 Function Code; 

Application message 

(Class of Service) 
Status/Return Code message 
Begin Session 
End Session (normal) 
End Session (error) 
Clear Request (request terminate) 
System Up ;L V: 
System Down 
Echo 

System Message 

Prepare to bring System Down Byte 3 Data 



Mode (bit flags) 

bits 0-7 Compaction 

Encription 

Response Expected 

Response 

Unsolicited Message 

Logging required 



Timeout Message Required 



Source ID 

bits 0-7 Region ID (hexadecimal) 

bits 8-19 xxxx xxxx xxxx Unit: Source 

application id if in Application 

mode 

xxxx xxxx xxxx Unit: Source 
Concentrator unit if in Reception 
System mode 
bits 2 0 - 2 3 xxxx Id Mode e.g., 

Reception mode 
Reception mode 
Server 205 Application 
mode 

//Server 2 05 Application 
mode 
Reserved 

bits 24 - 31 xxxx xxxx Sub-unit ID (hexadecimal) 

Byte 8 Logon Sequence Number (hexadecimal) Byte 9 Message 

Sequence Number (hexadecimal) Bytes 10 - 13 Destination ID 
bits 0-7 Region ID (hexadecimal) 

bits 8-19 xxxx xxxx xxxx Unit: Destination 

application ID if in 
Application mode 
xxxx xxxx xxxx Unit: Destination 

Concentrator if in 
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bits 2 0 - 2 3 xxxx 



irS ii 



bits 24 - 31 xxxx xxxx 
Bytes 14 - 15 Text Length 



Reception System mode 
Id Mode ; e . g . , 
Reception mode 
Reception mode 
Server 205 Application 
mode 

Server 205 Application 
mode 

Cache 302 Application 
mode 

Reserved 

Sub-unit ID (hexadecimal) 



With regard to FM2 or Type 2 messages, when an application is 
transmitting a large message, the sending application or its 
controlling switch can slice up the message into a number of 
smaller messages. The FM2 message header is used to indicate how 
these smaller messages can be reassembled into a single logical 
message by the receiving application or its controlling switch. 



In preferred form, the maximum logical message size is 64K. The 
maximum message block size is IK including all headers. Block 
sequence numbers in the FM2 range from 1 to a maximum of 255. 
And a single block message will be sequenced as block 1 of 1 in 
the FM2. 
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^When network objects are large (greater than IK bytes) they are 
sliced up into smaller blocks. Each object block is prefaced by 
an "object block header". Object block headers are found in the 
application text portion of a message. Object block headers 
provide sequencing information to cache/concentrator 3 02. The 
presence of an object block header does not obviate the require- 
ment for an FM2 DIA header, except in the case of messages from 
the cache/concentrator down to RS 400. Both an object block 
header and a FM2 may be present in a message. Sequence numbering 
within object block, headers ranges from 0 to 255. A single block 
Object will be sequenced as-, block 0 of 0. 

Messages larger than IK are subdivided into IK blocks when 
being transmitted between the server switch 2 05, 
cache/concentrators 3 02, and reception systems 400. 

Header Type 2 (FM2) message header contain information about 
this dividing of large messages and is useful when re-construct- 
ing large messages. The fields for an FM2 message header are as 
follows: Header Length - length of header data including 

length field. Header Type - Bit 0 is header concatenation 




flag. 



Bits 1 - 



7 indicate current header type. Number 



of 



total number of blocks used to transmit the 



Blocks 



logical message. If the total number of blocks 



cannot be determined at the time the first or 



middle blocks of a message are being sent, 



this field may be set to zero. 
The last block of a message must contain 
the correct total number of blocks. Block 
Number - number of the current message block being 

transmitted. 

Further, the layout for a Type 2 header is as follows: 
Byte 0 Header Length (hexadecimal) Byte 1 Header 

Type 

bit 0 if '0' no other headers present 

if '1' concatenated header present 
Q bits 1-7 000 0010 Byte 2 Number 

1,1 of Blocks (hexadecimal) Byte 3 Current Block Number 



m 



^4 



MS 



(hexadecimal ) 



With regard to FM4 type headers, also referred to as Type "4", 
these headers have been designed for communications between 
network gateway interface applications and external computer 
IP systems. For Type 4 Headers, the fields are as follows: Header 
Length - length of header data including length field. Header 
Type - Bit 0 is header concatenation flag. 

Bits 1-7 indicate current header type. Network 
User - a seven byte field containing the internal ID ID 
of the network user on whose behalf a 

conversation is being held with the external 
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computer system. External Data - Reserved 

Mode Correlation Id a field reserved for use by the 

external 

computer system. The contents of this field 
will initially be set to zero when a 
conversation is initiated across a gateway. 
The external system may then set the contents 
of this field to any value desired. 
Subsequent messages originating from TTX 
within he bounds of a virtual subscriber to 
external host session will echo the contents 

Q of the .Correlation Id field back to the 

jjl external system. 



The layout for a Type 4 header is as follows: 
^ S Byte 0 Header Length (hexadecimal) 

O Byte 1 Header Type 

fy bit 0 if '0' no other headers present 

m if concatenated header present 

"■VV 

te bits 1-7 000 0100 Bytes 2-8 Network User Id 

(ASCII) Byte 9 External Data Mode 

0000 0000 Reserved Bytes 10 - n Correlation Id 
(binary, max length=8 bytes) 

Next are FM8 or Type 8 headers. Type 8 headers have been 
designed to provide secondary routing destinations. Their fields 
are as follows. 
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spader Length - length of header data including length 
field. Header Type - Bit 0 is header concatenation flag. 

Bits 1-7 indicate current header type. 
Secondary Destination - a symbolic name representing 

the ultimate 

destination for the message. 
The layout for Type 8 header is: 
Byte 0 Header Length (hexadecimal) 

Byte 1 Header Type 

bit 0 if '0' no other headers present 

if '1' concatenated header present 
O bits 1 - 7 000 1000 

M 

Uj Bytes 2-9 Symbolic Destination Name 



09 



CP 



For FM9 or Type 9 headers, the header has been designed to 
communicate to a VTAM application which provides various network 
^ management support functions. More specifically, the VTAM 

is: e 

|y application has been developed in order to provide: a general 
05 network management interface which both supports the network (by 
means of the DIA) and simplifies its maintenance. Additionally, 
VTAM application provides data transfer and remote command 
functions, the ability to write to, and read from, a centrally 
located and maintained database in order to archive statistics 
and other inter-network messages, and formatting of binary data 
into Hexadecimal Display. 



In the case of Type 9 headers, the fields are: 
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^^ader Length - length of header data including length 
field. Header Type - Bit 0 is header concatenation flag. 

Bits 1-7 indicate current header type. 
Function Code - indicates general message type. Reason Code 
- indicates message content. Flags - indicates 

application action to be performed. Text Length 
indicates length of subsequent text message. 

(Not including possible concatenated headers) 

The layout for type 9 headers is: 
Byte 0 Header Length (hexadecimal) 

Byte 1 Header Type 

bit 0* if '0' no other headers present 

if '1' concatenated header present 

bits 1-7 000 1001 Byte 2 Function 

Code; e.g. 

Command 
Statistics 
Alert 

Control Byte 3 Reason Code 

Backbone Alerts Message 

Reception-originated Alerts Message Byte 

4 Flags 

bits 0-3 1... Store by Key - 8 char name follows 

. 1 . . Retrieve by Key - 8 char name 

follows 
..1. Data is Binary 



... 1 Data is (ASCII) 
..00 Data is EBCDIC 
7 Reserved Byte 5 Text Length 

(if Flags = 1... or . 1.. then chars 0-7 
should be the storage key. It is recommended 
that record storage keys initially be the 
same as the Resource Name to which the data 
pertains. 

In the case of FM64 or Type 64 headers, the headers are used t 
transmit error and status messages between applications. 
Intermediate nodes need not examine the contents of the FM64 
headers except in the case of the CICS switch which must obtain 
the displacement to the application text. If applications 
subordinate to an application subsystem are not available, the 
subsystem would strip the application text from the message, 
concatenate an FM64 message to any other headers which are 
present in the inbound message, and return the message to its 
original source. 

Header Type 64 has been designed for the communication of 
status information between users, and prefaces architected 
message text. The fields for Type 9 headers are: Header Length 
length of header data including length field. 
Header Type - Bit 0 is header concatenation flag. 

Bits 1-7 indicate current header type. Status 
Type .~ indicates type of status communicated such as 



bits 4 - 



r 



status request or error. Data Mode 
indicates whether message text is ASCII or 

EBCDIC Text Length - Length of subsequent 

message text 

(Not including possible concatenated headers) , 



The header Type 64 layout is: 

Byte 0 Header Length (hexadecimal) 

Byte 1 Header Type 

bit 0 if.'O' no other headers present 

if '1' concatenated header present 
bits 1-7 100 0000 Byte 2 Status Type 

Information 



Status Request 



Error 

Terminate Byte 3 Data Mode ; e.g. 



W EBCDIC 
M 

H ASCII 

©J Binary Bytes 4-5 Text Length 



In accordance with the invention, it has been determined that 
in some cases it is desirable to pre-define certain application 
level message formats so that they may be consistently used and 
interpreted. The following discussion is devoted to architected 
message text formats which are processed at the application 
level. For FM9 message text, in order to accommodate 
"Reliability/Serviceability/Availability" RAS functions within 
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ne^^rk 10, a fixed format for "alerts" is defined in the pre- 
ferred embodiment. Particularly if it is defined as message text 
following an FM9 header. The FM9 Function Code Alerts Message 
would be as follows: 

Byte 0 Reserved value 

Byte 1 System Origin 

Byte 2 Internal/External flag 

Byte 3-5 Message Originator 

Byte 6-9 Message Number 

Byte 10 Severity indicator; e.g. 

Error 

Information 
Severe Error 

S 5 

jj^ Recovery Successful 

^ Warning Byte 11 

Reserved value Byte 12 - 14 Error Threshold 



VI 



O 



m 
m 



For FM64 message text, the application message text is always 
prefaced by the appropriate header which indicates whether 
message text is ASCII or EBCDIC. 

The FM64 message text fields are as follows: 

Action Field - indicates type of operator or application 

action to be performed Module Name - Sending 

application Id 
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Format of this field is SSSTnnnn where 
SSS = sender initials 

T = type 0 = Network standard for all 
gateways 1 = non-standard, gateway specific 

nnnn = Sender Site number 

- Number assigned by sender for reference 
This number is used to indicate specific error 
codes if the message is an error message (FM64 
stat type 8) . This number is used to indicate 
specific commands if the message is a status 
request (FM64 stat type 4) . Text 
Alphanumeric (Printable) text 

The FM64 Message Text . iky but., is : 
Byte 0 Action Field (alphanumeric) , e.g. 

Action 
Decision 
Information 

Wait Bytes 1-8 Module Name (alphanumeric) 
Bytes 9-12 Reference Number 

(display numeric) 
Default 

request user status 
user active 
user inactive 



Reference 
Number 




• 




user inactive - retry after interval 

store in user mailbox 

cache to server link failure 

request appl status 

Server to Host failure 

appl active 

appl inactive 

appl inactive - retry after interval 
message was undeliverable 
response was timed out 
Syncpoint 



Checkpoint 



Delay 



m 



appl. error codes Bytes 13 - n 



Text 



(alphanumeric) 




user transaction traffic. 



described below, application sessions may be used as pipes for 



establish a set of protocols to be used between originating users 



Turning next to co called "Backbone States" , as will be 



In this regard, it is desirable to 



and destination users. Further it is important for intermediate 



nodes to be aware of the status of connectivity with adjacent 



nodes and specifies some actions to take when messages are known 



to be undeliverable. 



In this context, it is to be noted that the system up" message 
is used to signal the start of application traffic between the 
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sw^^h applications* The originating application transmits an 
FMO with a system up function code and response expected. The 
receiving application swaps the SID/DID, sets the Response bit 
on, and returns the message. If the receiving application is not 
available no response will be returned and the message will time 
out . 

In the case of "system down" messages, the message is used to 
prepare the termination of the session between switch applica- 
tions. The originating application transmits an FMO with a 
session down function code and response expected. The originating 

p application sends an FM64 with "status type=terminate" , and data 

SI 

%*\ mode=EBCDIC FM64 text follows the header with "action field"=A 



^3 

fti 

■srs? 



(Action), "module name"=SSSxOnnnn, "reference number"=0, Text= ( 
TZ (timestamp=HHMMSS) , Number of current users = NNNNN) . The 
^ intended result is that the originating application will not 
£3 accept any messages inbound to the utility session. The respond- 
ing application will then have the opportunity to return out- 
standing responses across the utility session. The responding 
application then returns an FMO with System Down back to the 
originating application. 

For each "echo" messages, the echo message may be used to 
determine whether a major application is still available. Specif- 
ically, the originating application sends an application message 
to its gatewayed partner using a FMO with an echo function. The 
destination application swaps the SID/DID, set the response bit 
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oi^^id returns the message otherwise untouched, thus effecting 



echo. 



For "APPL status request messages, the message is used to 
determine the status of a major application between nodes. 

Continuing, for "unsolicited application status posting" 
messages these messages are used for transmission of application 
status messages by unsolicited application (No response expected) 
across a nodes. For the message, the originating application 
wishes to post an application status to its partner in another 

O node. This message may be on the behalf of the originating 

Sjj 

m application itself or on behalf of another application. 

.M-RS. 

yy 
63 

1^ Turning next to user to internal APPL messages, and with regard 

to "session beginning", it is to be noted these messages normally 
arise at the start of conversation between a user and an internal 
application. For them the network user sends an FMO with a 
jg "begin session" function code and "response expected". The 

responding application swaps the SID/DID, supplies a "correlation 
Id", and returns both the FMO with the response bit set. 

In the case of rejection of a conversation initiation requests, 
the originating application transmits an FMO with a "begin . 
session" function code and "response expected" . The responding 
application swaps the SID/DID, and returns the FMO with the 
response bit set as well as a function code of "abend" session. 
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"applications" messages, these messages normally arise at 
the middle of conversation between a network user and an internal 
application. In this case, the originating user transmits and 
FMO with an "application" message function code, and "response 
expected". The responding application swaps the SID/DID, sets 
the response bit on and returns the response. 

"End session" messages typically arise in connection with 
unconditional termination of user/ internal application sessions. 
The originating transmits an FMO with an "end sessions" function 
code. Here however, no response is expected from the correspond- 
ing application. 

For an "end session abnormal" message, the message uncondi- 
tionally terminates an application conversation "abend" 

Continuing, "request terminate" messages cause conditional 
termination of session with an internal application. 

For messages concerning "rejection of a request due to link 
failure", in the case of server 205 to host link, the originating 
application transmits and FMO with "response expected". The 
message is intercepted by server 205 which recognizes it as 
undeliverable. A server 205 application returns the message with 
an FM64 message after stripping the application text. 



-85- 



messages concerning rejection of request due to link 
failure, in the case of communication between the 
cache/concentrator 302 and server 205, the originating applica- 
tion transmits an FMO with Response Expected. The message is 
intercepted by the cache/concentrator 205 which recognizes it as 
undeliverable. A cache/concentrator application returns the 
message with an FM64 message after stripping the application 
text. 

For messages concerning "conditional terminate rejected", the 
message is issued where a conditional termination of application 
conversation is not accepted by partner application. 

For "user continuity posting" messages, the message is used 
where the originating application wishes to post the status of a 
user to its partner application across the gateway 210. 

Continuing, for "user continuity requests", the message is used 
where an external application requests logon status of a 
particular network user. 

In the case of "application error" messages, the messages is 
used where transmission of application error message by respond- 
ing application is required. 

Still further, for "timeout scenarios", and specifically, 
"timeout scenario with timeout response required", the 



or^^nating user sends an application message to an internal 
application with "data mode" = "response expected" and "timeout 
response" required. The originating switch sets a timer for each 
"response expected" outbound message. If a response is not 
received before the switch timeout value is reached the switch 
2 05 sends a message with an FM64 header having a "timeout refer- 
ence" code to the originating application. 

For "response occurs after timeout" messages, the originating 
user sends an application message to an internal application with 
"response expected". The originating switch sets a timer for 
P each "response expected" outbound message. If a response is 
yj received after the timeout value is exceeded, server 2 05 switch 
S routes the message to a server 205 application which may log the 
message as non-deliverable, ship the message to the user, or drop 
it depending on the FMO class of service option specified on the 
original request message. 



SI 



In the case of "maximum resources scenario" messages, the 
originating user transmits a message to a destined internal 
application. The destination switch determines that no resources 
are currently available to support the transmission, and returns 
the message to the originator, after inserting an FM64 with a 
"status=error and FM64 text with an "action=wait . The originat- 
ing user may then retry or take other action. 
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Finally, the following graphic example illustrates normal 
message flow. 



Use 



Origin 
Switch 



Destination 
Switch 



APPL 



SI 

e s 6 



03 



si 



I 



| System Up 

I < 

| System Up RSP 

l 



Begin Session (User 1) 



Begin Session (User 2) 



Response User 1 



Response User 2 



Application Message User 1 | 



Response User 1 
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m 
iji 



End Session (User 1) 



I 



Request Terminate (User 2) 



i 



| System Down 

i < __ — 

| System Down RSP 



Response User 2 



ijpO 



Turning next to messages passed over gateways 210, the normal 
exchange of messages between the network and external parties 
occurs between two applications; i.e., the server 205 network 
message handler (NMH) . The server Switch 205 is an application 
which is written and maintained by network 10 and resides on it. 
The message handler resides on the other side of gateway 210 from 
network 10 and may be written and maintained by the external 
party; i.e., suppliers of information to network 10 such as Dow 
Jones . 
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session between the two applications is used as a pipe for 
the communications between many network users and a variety of 
applications external to the network. In this design, the switch 
server 205 has three primary responsibilities. It must pass 
network originated messages across the gateway to the network 
message handler. It must distribute messages returning across 
gateway 210 to the appropriate network applications or users, 
i.e. RS 4 00. Additionally, it must manage the continuity of a 
network user session with the external service provider. 
Typically, users enter into a conversation with a set of transac- 
tions. This set of transactions is referred to as a task. These 
tasks are called user sessions. The boundaries of these tasks 
are indicated by begin session/end session flags. 

The network message handler also has several responsibilities 
It must pass externally originated messages across gateway 210 to 
the switch server 2 05 at network 10. It must distributed 
messages returning across gateway 210 to the appropriate external 
applications. And, it must be able to communicate the availabil- 
ity of external applications to network switch server 205. 

With regard to gateway messages, in the case of "application to 
application" messages, and for "system up" messages, the system 
up message is used to signal the start of application traffic 
between switch 205 and the network message handler. The 
originating application transmits an FMO with function code 
"system up", and "response expected". The receiving application 



sw^ the SID/DID, sets the response bit on, and returns the 
message. If the receiving application is not available no 
response will be returned and the message will time out. 

Continuing for gateway "system down" messages, the system down 
message is used to prepare the termination of the session between 
the switch 2 05 and the NMH. The originating application 
transmits an FMO with function code "session down" and "response 
expected. The originating application sends an FM64 with "status 
type"="terminate" , "data mode"="EBCDIC" . FM64 Text follows the 
header with "action f ield"="A" (Action) , "module 
name"="SSSxOnnnn" , "reference number"="0" , 

"text"=( ( times tamp=HHMMSS) , number of current users = NNNNN) . 
The intended result is that the originating application will not 
accept any messages inbound to the utility session. The respond- 
ing application will then have the opportunity to return out- 
standing responses across the utility session. The responding 
application then returns an FMO with system down back to the 
originating application. 

Further, for "prepare to bring system down" messages, the 
message is used to prepare the termination of the session between 
the Switch 205 and the NMH. The originating application trans- 
mits an FMO with function code "prepare system down" . The 
responding application transmits an FMO with function code 
"session down" and "response expected". The responding applica- 
tion sends an FM64 with "status type"="terminate" , "data 



mc^^" = "EBCDIC" . FM64 Text follows the header with "action 
f ield" = "A fl (action), "module Name"="SSSxOnnnn" , "reference 
number"="0" / "text"= ( (Timestamp=HHMMSS) , number of current users 
= NNNNN) . The intended result is that the responding application 
will not accept any messages inbound to the utility session. The 
originating application will then have the opportunity to return 
outstanding responses across the utility session. The originating 
application then returns an FMO with "system down" back to the 
responding appl icat ion . 

For "echo" messages, the message may be used to determine 
whether a major application is still available. The originating 
application sends an application message to its gatewayed partner 
using a FMO with function echo. The destination application 
swaps the SID/DID, set the response bit on and returns the 
message otherwise untouched. - . 

In the case of "APPL status request" , the request is used to 
determine the status of a major application across the gateway. 

Continuing, for "unsolicited application status posting 
messages, the message is used for transmission of application 
status messages by unsolicited applications no response expected 
across a gateway. In this case the originating application 
wishes to post an application status to its partner across the 
gateway. This message may be on the behalf of the originating 
application itself or on behalf of another application. 



network to use "external APPL" messages, within the case of 
"begin session" messages, the message is used for normal start of 
conversation between a and an external application. The user, 
i.e. RS 4 00 sends an FMO with function "begin session" and 
"response expected", as well as an FM4 with null value in the 
"correlation id". The responding application swaps the SID/DID, 
supplies a Correlation ID, and returns both the FMO with the 
response bit set and the FM4 . 

For rejection of a conversation initiation request, the 
originating application resident application, transmits an FMO 
with function Begin Session and Response Expected as well as an 
FM4 with NULL value in the Correlation ID. The responding 
application swaps the SID/DID, and returns the FMO with the 
response bit set as well as a function code of ABEND session. The 
responding application also returns the FM4 . 

Further, for "applications" message, the message is used for 
normal middle of conversation between a network user and an 
external application. The originating user transmits an FMO with 
function code "application" message, and "response expected". It 
also supplies the TTXUID and the correlation id received on the 
begin session response back to the corresponding application 
across the gateway. The responding application swaps the 
SID/DID, sets the response bit on and returns the FMO and FM4 . 



"end session" message, the message is used for uncondi- 
tional termination of user/ external application sessions. The 
originating user transmits an FMO with function code "end ses- 
sion", no "response expected". Additionally it sends an FM4 
containing the TTXUID and the echoed "correlation id" in an FM4 . 
No response is expected from the corresponding application. 

For "end session abnormal" messages, the message is used for 
unconditional termination ABEND of gatewayed application conver- 
sation. 



05 



OS 



In the case of "request terminate", the message is used for 
conditional termination of user session with an external applica- 
tion. 

For "conditional terminate rejected" messages, the message is 
used for a conditional termination of application conversation 
not accepted by partner application across a gateway. 

For "user continuity posting" messages, the message is used 
where the originating application wishes to post the status of a 
user to its partner application across the gateway. 

In the case of "user continuity" request, external application 
requests logon status of a particular user, i.e. RS 4 00. 
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"application error" messages, the message is used for 
transmission of application an error message by responding 
application across a gateway. 

In the case of "delayed response" messages, the originating 
application sends an application message to its gatewayed partner 
using the minimally a FMO and a FM4 FM64 may be present. The 
destination switch signals an application on the originating side 
that the response may be slow by sending a FMO with function code 
"status/return", the response bit is not set. The FM4 is re- 
turned, and an FM64 "status", FM64 text "Action"=" Information" is 
also sent. Slow response may be due to a number of factors such 
as function shipping requirements or many I/Os. In parallel, the 
gateway partner application processes the message according to 
normal flow. 

For "timeout scenario", the originating user sends an 
application message to an external application with "response 
expected". The switch server sets a timer for each "response 
expected" outbound message. If a response is received after the 
timeout value is exceeded, the TPF switch routes the message to a 
TPF application which may log the message as non-deliverable, 
ship the message to the user, or drop it depending on the FMO 
class of service option specified on the original request mes- 
sage. 





the "maximum resources scenario" messages, the originating 
user transmits a message to a destined external application. The 
network message handler determines that no resources are 
currently available to support this transmission. The network 
message handler returns the message to the originator, after 
inserting an FM64 with a "Status"="Error" and FM64 text with an 
"action=wait" . The originating user may then retry or take other 
action. 

Finally, an example illustrates normal message flow. 
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I Response User 2 



I 



Application Message User 1 | 



Response User 1 



i 



5 . 5 

OS 
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m 



End Session (User 1) 



Request Terminate (User 2) 



I Response User 2 



I 
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| System Down | 

I < | 

| System Down RSP | 



And, the following is an example that illustrates premature 
loss of user connectivity due to the loss of connection between 
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th^^etwork switch server 2 05 and a cache/concentrator 3 02. In 

this case, an application peripheral to switch 2 05 posts the user 
status inactive to the NMH using an FM64 Ref=0008 user inactive. 
External application reaction to this posting is implementation 
dependent. In this example, the external application returns 
outstanding responses using the FM64 "ref l, ="mailbox option". 
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In accordance with the invention, in order to enable the 
manipulation of the network objects, the application programs 



ne^J^sary to support the interactive text/graphic sessions are 
written in a high-level language referred to as "TBOL", TRINTEX 
Basic Object Language (TRINTEX is the company developing the 
technology that constitutes this invention) . TBOL is specifical- 
ly adapted for writing the application programs so that the 
programs may be compiled into a compact data stream that can be 
interpreted by the application software operating in the user 
personal computer, the application software being designed to 
establish the network Reception System 400 previously noted and 
described in more detail hereafter. 

Q In accordance with the invention, the Reception System 

SI 

id application software supports an interactive text/graphics 

CO 

CO 



UJ 



M 



sessions by managing objects. As explained above, objects 
specify the format and provide the content; i.e., the text and 
graphics, displayed on the user's screen so as to make up the 
pages that constitute the application. As also explained, pages 
are divided into separate areas called "partitions" by certain 
objects, while certain other objects describe windows which can 
be opened on the pages. Further, still other objects contain 
TBOL application programs which facilitate the data processing 
necessary to present the pages and their associated text and 
graphics . 

As noted, the object architecture allows logical events to be 
specified in the object definitions. An example of a logical 
event is the completion of data entry on a screen; i.e., an 

-99- 



/ 



aj^^Lcation page. Logical events are mapped to physical events 
such as the user pressing the <ENTER> key on the keyboard. Other 
logical events might be the initial display of a screen page or 
the completion of data entry in a field. Logical events speci- 
fied in page and window object definitions can be associated with 
the call of TBOL program objects. 



Reception Systems 4 00 is aware of the occurrence of all 
physical events during the interactive text/graphic sessions. 
When a physical event such as depression of the forward tab key 
corresponds to a logical event such as completion of data entry 

O in a field, the appropriate TBOL program is executed if specified 

SI 

W in the object definition. Accordingly, the TBOL programs can be 

CO 

OS thought of as routines which are given control to perform ini- 

U| tialization and post-processing application logic associated with 

CP 

the fields, partitions and screens at the text/graphic sessions. 

H 

^ Reception System 4 00 run time environment uses the TBOL 

65 

£0 programs and their high-level commands called verbs to provide 

all the system services needed to support a text/graphic session, 
particularly, display management, user input, local and remote 
data access. 



In accordance with the invention, the TBOL programs have a 
structure that includes three sections: a header section in which 
the program name is specified; a data section in which the data 
structure the program will use are defined; and a code section in 
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wt^^i the program logic is provided composed of one or more 
procedures. More specifically, the code section procedures are 
composed of procedure statements, each of which begins with a 
TBOL key word called a verb. 

In accordance with the invention, the name of a procedure can 
also be used as the verb in a procedure statement exactly as if 
it were a TBOL key word verb. This feature enables a programer 
to extend the language vocabulary to include a customized 
application-oriented verb commands. 

Continuing, TBOL programs have a program syntax that includes 
series of "identifiers" which are the names and labels assigned 
to programs, procedures, and data structures. 

An identifier may be up td 31 characters long; contain only 
uppercase or lowercase letters A through Z, digits 0 through 9, 
and/or the special character underscore (_) ; and must begin with 
a letter. Included among the system identifiers are: "header 
section identifiers" used in the header section for the program 
name; "data section identifiers" used in the data section for 
data structure names, field names and array names; and finally, 
"code section identifiers" used in the code section for identifi 
cation of procedure names and statement labels. 

The TBOL statement syntax adheres to the following conventions 
Words in uppercase letters are key words and must be entered 



ex^^ly as shown in an actual statement. When operand are 

allowed, descriptive operand names and lowercase letters follow 

the key word. In this arrangement, operand names or literals are 

entered in an actual statement. Operand names enclosed in square 

brackets ( [ ] ) are optional and are not required in an actual 

statement. Operand names separated by a bar (|) mean that one, 

and only one, of the separated operand can be included in an 

actual statement. Operand names followed by an ellipsis (...) 

can be entered 1 or more times in an actual statement. Model 

statement words not separated by punctuation must be separated by 

at least one blank (or space character) in actual statements. 

□ Model statement punctuation such as comma ( , ) , semicolon ( ; ) , 
Si 

less-than sign (<) , equal sign (=) , greater-than (>) , and 



parentheses (()) must be included where shown in actual 
statements. Square brackets ([]), bars (|), and ellipses (...) 
should not be included in actual statements. 



fy An example of a model statement would be as follows: 
GOTO_DEPENDING_ON index, label ( . label . . . ) ; 



This model says that a valid GOTO_DEPENDING_ON statement must 
begin with the word "GOTO_DEPENDING_ON" followed by at least one 
blank. Thereafter, an "index" and a "label" separated by a comma 
must be included. The index and at least one label are required. 
Additional labels may also be used, provided each is preceded by 



-102- 



a^^nma. Further, the statement must have a semicolon as the 
last character. 

Comments can be included in a TBOL program on a statement line 
after the terminating semicolon character or on a separate 
comment line. Comment text is enclosed in braces ({}). For 
example: {comments are enclosed in braces}. Comments can be 
placed anywhere in the source code stream since, in accordance 
with the invention they are ignored by the TBOL compiler. 
Additionally, blanks (or space characters) are ignored in TBOL 
statement lines except where they function as field separators. 

As noted, TBOL programs have a structure that includes a header 
section, data section and code section. More particularly, every 
TBOL program must have a header section. The header section 
contains a PROGRAM statement. The PROGRAM statement contains the 
key word PROGRAM followed by the name of the program. For 
example: PROGRAM program_name ; where "program_name" is an 
identifier; i.e., the name of the program. 

Accordingly, the header section for a TBOL program called LOGON 
would look like as follows: 

PROGRAM LOGON: {User logon program} 

The data section in a TBOL program begins with the key word 
DATA which is followed by data structure statements. The 
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st^^ture statements contain the data structure definitions used 
by the program. If the data structure does not have to be 
defined for the program it can be omitted. However, if a TBOL 
program does not include a data section, it must use a more 
restricted structure, more fully explained hereafter. 

As an example, the data syntax would be: DATA structure 
[structure...] where "structure" is a data structure statement. 
The data structure statement contains a definition, which con- 
sists of the data structure name followed by an equal sign and 
then the names of one or more variables. For example: struc- 
ture_name=variable_name [ , variable_name . . . ] ; where "struc- 
ture_name" is an identifier; i.e., the name of the data struc- 
ture; and n variable_name" is an identifier for the variable; 
i.e., the name of a variable. 

All of the variables in the data structures are defined as 
string (or character) variables. TBOL string variables are of 
two kinds, fields and arrays. In the case of filed definitions, 
a variable field is defined with and identifier; i.e., the name 
of the field. No data type of length specification is required. 
An individual field is referenced by using the field name. 
Further, subsequent fields can be referenced by using a field 
name followed by a numeric subscript enclosed in parentheses 
(()). The subscript however, must be an integer number. 
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^^field name followed by a subscript refers to a following 
field in the data section of a TBOL program . The subscript base 
is 1. For example, if a field CUST_NBR were defined, then 
CUST_NBR refers to the field CUST_NBR, CUST_NBR(1) also refers 

to the field CUST_NBR and CUST_NBR(2) refers to the field follow- 
ing CUST_NBR. 

In the case of array definitions, the TBOL array is a 
one-dimensional table (or list) of variable fields, which can be 
referenced with a single name. Each field in the array is called 
an element. 

An array can be defined with an identifier, particularly, the 
name of the array, followed by the array's dimension enclosed in 
parentheses (()). The dimension specifies the number of elements 
in the array. By way of illustration, if an array is defined 
with a dimension of 12, it will have 12 elements. An individual 
element in an array is referenced by using the array name 
followed by a numeric subscript enclosed in parentheses (())• 
The subscript indicates the position of the element in the array. 
The first element in an array is referenced with a subscript of 
1. The subscript can be specified as either an integer number or 
an integer register as described, hereafter. 

With regards to variable data, data contained in variables is 
always left-adjusted. Arithmetic operations can be formed on 
character strings in variables if they are numbers. A number is 



a ^J^practer string that may contain only numeric characters 0 
through 9, an optional decimal point, an optional minus sign in 
the left-most position, commas and the dollar sign ($) . 



When you perform an arithmetic operation on a character string, 
leading and trailing zeros are trimmed and fractions are 
truncated after 13 decimal places. Integer results do not 
contain a decimal point. Negative results contain a minus sign 
(-) in the left-most position. 

Each field and each array element has a length attribute which 
is initialized to zero by the Reception System at program 
startup. The LENGTH verb, to be described more fully hereafter, 
can be used to set the current length of a field or array element 
during program execution. The maximum length of a field or an 
array element is 65,53 5. 

Further, the maximum number of variables that can be defined in 
the data section of a TBOL program is 222. This number includes 
fields and array elements. 

The following example data section contains five data structure 
statements, each defining a data structure. Each structure 
statement begins with the name of the data structure followed by 
an equal sign. 
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}t, are the names of the variables which make up the 
structure. The variable names are separated by commas. The last 
variable name in each structure statement is followed by a 
semicolon which terminates the statement. 

The third data structure given, i.e. SALES_TABLE, contains two 
arrays. The others contain fields. The last structure 
statement, i.e. WK_AREA is and example of a single line. 



DATA 

BILL_ADDR= 
BILL_NAME, 
BILL_ADDR1, 
BILL_ADDR2 , 
BILL_ADDR3 ; 
SHIP_ADDR= 
SHIP__NAME, 
SHIP_ADDR1, 
SHIP-ADDR2 , 
{field4 SHIP_ADDR1) 
SALES TABLE= 
MONTH QUOTA (12) , 
MONTH SALES (12) ; 
MISC_DATA= 
SALES PERS_NAME , 
CUST_TELNBR ; 
WK_AREA=TEMP1 , TEMPI 



{Key word DATA begins data section} 
{data structure BILL_ADDR) 

{fieldl BILL_NAME} 

{field2 B1LL_ADDR1} 

{ f ield3 BILL_ADDR2 } 

{field 4 BILL_ADDR3 } 
{data structure SHIP_ADDR } ) 

{fieldl SHIP_NAME } 

{field2 SHIP_ADDR1} 

{field3 SHIP_ADDR1) SHIP_ADDR3 , 

(data structure SALES_TABLE) 
{arrayl MONTH_QUOTA } 
(array 2 MONTH__S ALES ) 
{data structure MISC_DATA) 
{fieldl SALESPERS_NAME } 

{field2 CUST_TELNBR } 
{data structure WK_ARE A } 
-107- 



^^rtinuing, TBOL contains a number of predefined data 
structures which can be used in a TBOL program even though they 
are not defined in the program's data section. There are two 
kinds of TBOL-def ined data structures, these are "system regis- 
ters" and "external data structures". 

In the case of systems registers, tree different types exist. 
The first type are termed "integer registers" , and are used 
primarily for integer arithmetic. However, these registers are 
also useful for field or array subscripts. The second type are 
termed "decimal registers", and are used for decimal arithmetic. 
The third type are called, "parameter registers" and are used to 
pass the data contained in procedure statement operand when the 
name of a procedure is used as the verb in the statement rather 
than a TBOL keyword. 

The variables defined in the data section of a program are 
string (or character) variables, and the data in them is kept in 
string format. In most cases there is no need to convert this 
data to another format, since TBOL allows substantially any kind 
of operation (including arithmetic) on the data in string form. 
As will be appreciated by those skilled in the act, this elimi- 
nates the clerical chore of keeping track of data types and data 
conversion. 

There are some cases where it is desireable to maintain numeric 
data in binary integer or internal decimal format. For example, 
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ar^^>plication involving a great deal of computation will execute 
inore efficiently if the arithmetic is done in binary integer or 
internal decimal format data rather than string data. In these 
cases, data conversion can be performed by simple moving the 
numeric data to the appropriate register. When data is moved 
from a register to a variable, it is converted to string format. 

Integer registers are special-purpose fields for storing and 
operating on integer numeric data in binary format. The integer 
registers are named. II through 18. Numeric data moved to an 
integer register is converted to an integer number in binary 
format. Further, an attempt to move non-numeric data to an 
integer register will cause an error. The largest negative 
number an integer register can hold is -32,7767, while the 
largest positive number than can be held is 32,767. An noted 
arithmetic operations in integer registers will execute more 
efficiently than arithmetic operations in string variables. 

Decimal registers are special-purpose fields for storing and 
operating on numeric data in internal decimal format. The 
decimal registers are named Dl through D8 . Numeric data moved to 
a decimal register is converted to a decimal number in internal 
decimal format. An attempt to move non-numeric data to a decimal 
register will cause an error. The largest negative number a 
decimal register can hold is -9999999999999.9999999999999, while 
the largest positive number a decimal register can hold is 
9999999999999.9999999999999. Additionally, decimal registers can 



nc^J^e used as field or array subscripts. And, again, arithmetic 
operations in decimal registers will perform better than arithme- 
tic operations in string variables. 

As pointed out above, the code section of a TBOL program 
contains the program logic, which itself is composed of one or 
more procedures. In the logic, the procedures are expressed as 
procedure statements. Each procedure statement begins with a 
TBOL keyword called a verb which is followed by operand, or 
parameters containing the data on which the verb is to operate. 
The name of a procedure can be used as the verb in a procedure 
Q statement exactly as if it were a TBOL keyword verb. As noted 



M 

M 



this enables the creator of a TBOL program; i.e. the party 
creating the text/graphic session, to extend the language vocabu- 
lary to include his own application-oriented verb commands. 



Q When a procedure is used as the verb in a procedure statement, 

SI 

ni TBOL saves the current parameter register values, and the 

|S{ parameter data in the verb operands is moved into the parameter 

^ registers where it is available to the "called" procedure. When 

the "called" procedure returns, TBOL restores the saved parameter 

register values. 



Parameter registers are special-purpose fields for passing 
parameter data to "called" procedures. The parameter registers 
are named PO through P8 . When a procedure is "called" by using 
its name as the verb in a procedure statement, the current 

-110- 



Ar^^ definition segments 548 define the names and relative 
locations of fields in a row that makes up an array or table. 
The first row of fields must have been defined using field 
definition segments 516. The array definition provides a short- 
hand for specifying the replication of selected fields from the 
initial page. The structure of the array definition segment 548 
is as follows: 

<st> <sl> <#occurrences> <vertical gap> <f ield name> . . . 

where " foccurrences" is a one-byte field describing the number of 
rows to be generated to create the array (the first row is 
assumed to be generated from field definition segments 516) ; 
"vertical gap" is a NAPLPS point set operand (relative, invisi- 
ble) containing the DY of inter-row spacing; and "field name" is 
a one-byte name (from the field definition) of the fields in a 
row of the array. CUSTOM GRAPHICS SEGMENT 

Custom graphics segment 550 provides a means to package graphics 
commands. These graphics commands may be related to a field and 
initiated based on run-time conditions. The structure of custom 
graphics segment 550 is as follows: 

<st> <sl> <id> <size> <NAPLPS> 

where "id" is a one-byte identifier for this custom graphic; 
"size" is a three-byte NAPLPS operand specifying upper right 



cont^^s of PO through P8 are saved. Further, data from the 
first operand in the procedure statement is placed in PI; data 
from the second operand is placed in P2 ; and so on, up to eight 
operands. If no operand, or less than eight operand are speci- 
fied, the parameter registers corresponding to the missing 
operand are set to null. In accordance with this arrangement, 
the number of operand is placed in PO, and the "called" procedure 
is given control. 

When control returns to the "calling" procedure from the 
"called" procedure, the previous contents of PO through P8 are 
P restored. Following execution of the "called" procedure, execu- 
U tion of the "calling" procedure continues. 

Off 

b j : 

The "calling" procedure can pass along its own parameters to 
CP the "called" procedure by naming parameter registers as operand. 
Q The TBOL internal stack can be used to pass additional data to 
IU the "called" procedure, or to pass data back to the "calling" 
m procedure. 



€1 



There are two kind of TBOL-def ined external data structures; 
they are partition structures and global structures. With regard 
to partition external data structures, as noted above the screens 
displayed during a test/graphic session are called pages. As 
also noted, pages may be divided into separate areas called 
"partitions". Each page partition has its own predefined parti- 
tion external data structure. Each partition external data 
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stri^^are can contain up to 256 variables for data pertaining to 
that partition. A TBOL program associated with a particular 
partition has access to the partition's external data structure 
and the variables it contains. However, the program cannot 
access another partition's external data structure. 

The variable in a partition external data structure are 
character string variables like those defined in the data section 
of a program. The variables within each partition external data 
structure are named &1 through &256. The DEFINE compiler direc- 
tive enables the program to use meaningful names for these 

H variables in the program source code. 

%j 

m 

£0 Partition external variables are used to hold screen field 

ypj data, program flow data and applications data. In the case of 
screen field data, when page and window objects are defined, the 
JJj fields m the screen partitions are assigned to partition exter- 
■Lj nal variables. The TBOL Object Linker resolves these references 
and at program execution time the Reception System transfers data 
between the screen fields and their associated partition exter- 
nal variables. The TBOL program has access to the variables, 
which contain the data entered in the screen fields by the user, 
and the user has access to the screen fields of which contain the 
data placed in the variables by the program. 



For program flow data, partition external variables are used 
to hold the object identifiers needed by a TBOL program for 
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trai^^rring control. These may be page object identifiers for 
transfer to another text/graphic screen page, or window object 
identifiers needed to open a window on the current page. As in 
the case of screen field data, flow data values are placed in 
partition external variable by the TBOL Object Linker. 

Finally, for application data, partition external variables 
can be used to hold partition-specific application data such as 
tables of information needed by the program to process the 
expected screen field input. 

O With regard to the global external data structure, the 

yj predefined global external data structure can contain up to 

gjj 32,000 variables for TBOL system data. All TBOL programs have 

N= 

access to the global external data structure and the variables it 

?*% 

contains. The variables in a global external data structure are 

s 

O character string variables like the ones one defines in the data 
FU section of a program. The global external variables are named #1 
ffl through #32,000. These variables are assigned and controlled by 
^ the TBOL database administrator which maintains a file of DEFINE 
compiler directive statements which assign meaningful names to 
the global external variables in use. In the preferred embodi- 
ment, the MS-DOS file specification for this file can, for 
example be TBOLLIB\TBOL. SYS . In this regard, the COPY compiler 
directive is used to copy TBOL. SYS into a source code input 
stream. Subsequent statements in the program source code can 
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refe^^ce the global external system variables by using the 
meaningful names assigned by the DEFINE statements in this file. 

Examples of global external variables are: SUS_RETURN_CODE , 
which is assigned a return code value after the execution of 
certain TBOL program verb statements; SYS_DATE, which contains 
the current system date; and SYS_TIME, which contains the current 
system time. 

With regard to the TBOL program code section, as noted 
above, every TBOL program must have a code section. The code 

Q section contains the program logic which is composed of one or 

SJ 

W more procedures. In accordance with this arrangement, a proce- 

ft 5 ? 

£Q dure begins with the keyword PROC followed by an equal sign ( = ) 
^and then the name of the procedure. The body of the procedure is 

m 

~ composed of procedure statements, ending with the END_PROC 
?1 statement . For example: 

m 
m 

HS PROC=proc_name statement [statement. . . ] END_PROC; 



where n proc_name" is an identifier; i.e. the name of the proce- 
dure, and "statement" is a TBOL procedure statement as described 
below. 



In accordance with the invention, at program execution time, 
control is given to the first procedure in the program. This is 
the mainline procedure. From then on, the flow of procedure 
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exec^^-on is controlled by the logic contained in the procedures 
themselves ♦ 



Each procedure statement begins with a TBOL keyword called a 
verb. However, as noted above, the name of a procedure can also 
act as the verb in a procedure statement, exactly as if it were a 
TBOL verb. In such case, the data in any statement operand is 
moved into parameter registers and control is passed to the other 
procedure. No special linkage or parameter passing conventions 
are needed. As will be appreciated by those skilled in the art, 
this is a powerful feature which enables the application program- 
s' mer to extend the language vocabulary to include his own library 
M 

yj of application-oriented verb commands and commonly used proce- 
03 

« dures . 

^ When control is transferred to another procedure, as noted, 

Q the "called" procedure returns control to the "calling" procedure 

fU with a RETURN or END_PROC statement, where RETURN and END_PROC 

.to 

jjg are TBOL verbs described more fully hereafter. Upon return, the 
"calling" procedure's parameter data, if any, is restored in the 
parameter registers, and program execution resumes with the next 
statement. Recursive logic is possible by using the name of the 
current procedure as the verb in a procedure statement, thus 
causing the procedure to "call" itself. 



In accordance with the design of TBOL, any procedure state- 
ment may be preceded with one or more identifying labels. A 



labe^^sonsists of an Identifier followed by a colon (:). For 
example: 

(stmt_label : . . . ) statement 

where "stmt_label" is an Identifier, for the statement, and 
"statement" is a TBOL procedure statement. 

Procedure statement labels are used for transferring control 
to another statement within the same procedure using a GOTO or 
GOTO_DEPENDING_ON statement (TBOL verbs described more fully 

£3 hereafter) . 

SI 

y 

03 GOTO and or GOTO_DE PEN D I NG_ON statement can also be used to 

transfer control to another procedure. Transfer to another 
procedure is done by using the target procedure name as the verb 

s 

r 3 : in a statement. 
M 

ru 

CO 

C£! Also in accordance with the design of TBOL, all procedural 

AS. 

logic is constructed from statements designed to execute in three 
basic patterns: sequential, conditional, or repetitive. In the 
case of a sequential pattern, the sequential program logic 
consists of one or more procedure statements. In the case of a 
conditional pattern, the conditional program logic is constructed 
using IF ... THEN ... ELSE and GOTO_DEPENDING_ON key words, described 
more fully hereafter. Finally, in the case of a repetitive 
pattern, the repetitive program logic is constructed using 
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WHII^^.THEN key words or IF. - .THEN. . .ELSE and GOTO key words 
also described more fully hereafter. 



In accordance with the TBOL design, a procedure statement 
may contain operand following the verb. In the case of procedure 
statements , there are five types of procedure statement operand ; 
data names; group data names; system registers, label identifi- 
ers, and literals. In this arrangement, data names are the names 
of variables, and data name operand can be either field names; 
field numbers with subscripts or array names with subscripts. In 
the case of filed names, a field name is the identifier used as 

p the name of a variable in a data structure in the data section of 

St 

yj the program, or the name of TBOL-defined variable in an external 

m data structure. 

w 

m 

8^ For field names with subscripts, a field name followed by a 

S subscript enclosed in parentheses (()) refers to a following 

S.I 

fU field! The subscript must be an integer number expressed as a 

Kt 

^ literal or contained in a variable field. The subscript base is 
1. For example: CUST_NAME(1) refers to the field CUST_NAME , and 
CUST_NAME(2) refers to the field following CUST_NAME. 



For array names with subscripts, an array name is the 
identifier used as the name of an array in a data structure in 
the data section of the program. An array name followed by a 
subscript enclosed in parentheses (()), refers to an individual 
element in the array. The subscript must be an integer number 
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expi^^sed as a literal or contained in a variable field. The 
subscript base in 1, so the first element in an array is refer- 
enced with a subscript of 1. 

In the case of procedure statement group data name operand, 

the group data names are the names of data structures or arrays. 

Group data names are used in statements where the verb allows 

data structures or arrays to be treated as a single unit. For 

example, the TBOL MOVE verb allows the use of group data name 

operand. If the names of two arrays as group data operand are 

used, the contents of each element in the source array is moved 

p to the corresponding element in the destination array. Here the 

yj array names are specified without subscripts. However, if the 
09 

CO names of two data structures as group data operand are used, the 

!=£= 

In contents of each variable in the source data structure is moved 
to the corresponding variable in the destination data structure. 



fU With regard to system register operands, they can be either 

03 

integer registers II through 18, or decimal registers Dl through 
D8 , or parameter registers PI through P8 . 



In the case of label identifiers, the label identifiers are 
the identifiers used as procedure statement labels described 
above . 



Continuing, literal operand can be either, integer numbers, 
decimal numbers or character strings. Where the literal operand 
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are ^^iteger numbers, the integer is composed of the digits 0 
through 9. Where a negative integer is to be represented, a 
minus sign (-) is allowed in the left-most position. However, a 
decimal point is not allowed. Accordingly, the minimum value 
that can be represented is -32,767, and the maximum value is 
32,767. Where the literal operand is a. decimal number, the 
decimal number is composed of the digits 0 through 9 with a 
decimal point (.) where desired. A minus sign ( - ) is allowed 
in the left-most position. Thus the minimum allowable value is 
-9999999999999.99999999999999, and the maximum value is 
999999999 9999. 99999 99999999 . 

iji Further, where the literal operand is a character string, 

^ the character string is composed of any printable characters or 
^ control characters. Character strings are enclosed in single 
6^ quotes ('). To include a single quote character in a character 
O string, it must be preceded with the backslash character (\) . 
fU For example: V . To include a new-line character in a character 
|jj string, the control character- \n is used. For example; 'this 
w causes a new line: \n'. To include binary data in a character 
string, the hex representation of the binary data is preceded 
with the backslash character (\) . For example; 'this is binary 
01110111:\77' . 



The syntax of a complete TBOL program is illustrated in the 
following example program. 

HEADER SECTION PROGRAM program_name ; 
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DAT, 



:ction 



DATA 



data structure name-l= {1st data structure) 



variable_name_l , 



variable names 



variable name n ; 



data structures 



data structure_name_n= {nth data structure} 




variable_name_l , 



variable names followed by commas 




variable name n; 



{mainline procedure } 



CODE SECTION 



PROC proc_name_l= 



procedure statements 



IF x = x THEN EXIT: 



{ if done , return to 



Reception System} 



procedure statements 
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END PROC; 



SI 



PJ 



{end of mainline 
procedure) 



procedures 

PROC proc_name_n= 

procedure statements 

IF x = x THEN RETURN; 

procedure statements 
END-PROC ; 



{nth procedures) 



{if done , return to 
"calling"procedure } 

{end of nth 
procedure } 

{end of 

program) 



In accordance with the invention, the TBOL compiler enables 
portability of TBOL programs. Specifically, the TBOL compiler is 
capable of generating compact data streams from the TBOL source 
code that can be interpreted by any reception system configured 
in accordance with the invention, i.e., a personal computer 
running the reception system application software. For this 
arrangement, the compiler input file containing the TBOL source 
code may have any name. For example, the extension .SRC can be 
used . 
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^^uring the compilation, three files are generated. Their 
names are the same as the source code file; their extensions 
identify their contents. For example, when the file names 
INPUT. SRC is compiled the following files are generated by the 
compiler: INPUT. SYM which contains a symTBOL directory; IN- 
PUT. COD which contains the compiled code; and INPUT. LST which 
contains the listing. 

In order to resolve an undefined procedure, the TBOL compil- 
er automatically search the local MS-DOS directory TBOLLIB for a 
file named procname. LIB, where procname is the name of the 
P unresolved procedure. IF procname. LIB is found, the compiler 
m will automatically copy it into the source code stream after the 

is 

|¥| program source text has ended. 

iy!= In addition to the undefined procedures facility above 

O noted, the TBOL compiler also may be caused to substitute one 
fy text string for another. This accomplished by a DEFINE direc- 
tive. 

Wherever the text pattern specified in operand 1 is found in 
the source code stream, it is replaced by the compiler with the 
text pattern specified in operand 2. The syntax for the proce- 
dure is: 

DEFINE source_pattern , replacement_pattern ; 
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whe:^^ ll source_pattern" is the text in the source code which the 
compiler is to replace, and "replacement_pattern" is the text the 
compiler will use to replace source pattern . 

If source_pattern or replacement_pattern contain any blank 
(space) characters, the text must be enclosed in single quotes 
(') - 

Further, the compiler can be made to eliminate certain text 
from the input source stream by using a null text string for the 
replacement_pattern ( ' ' ) . 

D 

Si 

y It is to be noted that while DEFINE directives are normally 

~gj placed in the data section, they can also be placed anywhere in 

'ft the source code stream. For example, if the symTBOLic name 
US 

CUST_ NUMBER has been used in a TBOL application program to refer 

5: 

P to a partition external variable named &6. The DEFINE statement 
SI 

flj DEFINE CUST_NUMBER, . &6 would cause the compiler to substitute &6 
09 

whenever it encounters CUST_NUMBER in subsequent statements, 

wts? 

As a further illustration , if the words MAX and MIN are 
defined with numeric values, DEFINE MAX, 1279; and DEFINE MIN, 500; 
MAX and MIN can be used throughout the program source code rather 
than the actual numeric values. If the values of MAX and MIN 
change in the future, only the DEFINE statements will need to be 
changed. 
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:ill further, the compiler can also be caused to copy 
source code from some other file into the compiler input source 
code stream. This can be accomplished with a directive entitled 
COPY. With the use of the COPY directive, the source code 
contained in the file specified in operand 1 is copied into the 
source code stream at the point where the COPY statement is read 
by the compiler. For example, the syntax would be: COPY 
'filename'; where "filename" is the name of the file containing 
source code to be inserted in the source code steam at the point 
of the COPY statement* In this arrangement, file_name must be 
enclosed in single quotes (')# and file_name must conform to the 
£5 operating system file naming rules (in the current preferred 
yj embodiment, those of MS-DOS) . Further, the file referenced in a 
m COPY statement must reside in the TBOLLIB directory on the 
jj^ compilation machine. In accordance with the invention the COPY 
* % statement can be placed anywhere m the source code stream. 



FU By way of illustration, the COPY statement COPY 'TBOL. SYS'; 

03 causes the compiler to insert source text from the file TBOL.SYS 
This file is maintained by the TBOL Database Administrator, 
and contains DEFINE statements which assign meaningful names to 
the TBOL system variables in the global external data structure. 



As shown in Fig. , 28 verbs are associated with data 

processing; 2 0 with program-flow; 7 with communications; 6 with 
file management, 6 with screen management; 3 with object manage- 
ment and 2 with program structure for a total of 72. Following 
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is ^^alphabetical listing of the TBOL verbs, together with a 
description of its function and illustration of its syntax. 



ADD 

The ADD verb adds two numbers. Specifically, the number in 
operand 1 is added to the number in operand 2. Thus, the number 
in operand 1 is unchanged, while the number in operand 2 is 
replaced by the sum of the two numbers. The syntax for ADD is: 

ADD numberl , number2 ; , 



p where numberl contains the number to be added to number2 . In 

Si 

yj this arrangement, numberl can be a data name; system register or 
Sjj literal number. As is apparent, number2 contains the second 

number, and is overlaid with the resulting sum. Number2 can be a 

in 

data name or system register. 

q 

si 

fy TBOL will automatically perform data conversion when numberl 

05 

&k is not the same data type as number2 . Sometimes this will result 



in number2 having a different data type after the add operation. 
In accordance with this embodiment, fractions will be truncated 
after 13 decimal places, and whole numbers will not contain a 
decimal point. Negative results contain a minus sign (-) in the 
left-most position. 



AND 



-126- 



AND verb performs a logical AND function on the bits of 
two data fields. The logical product (AND) of the bits of 
operand 1 and operand 2 is placed in operand 2 . Moving from left 
to right, the AND is applied to the corresponding bits of each 
field, bit by bit, ending with the last bit of the shorter 
field. If the corresponding bits are 1 and 1, then the result 
bit is 1. If the corresponding bits are 1 and 0, or 0 and 1, or 
0 and 0, then the result bit is 0. In this arrangement, the data 
in operand 1 is left unchanged, and the data in operand 2 is 
replaced by the result. 



P The AND syntax is: 
SI 

w 

gg - AND f ieldl, f ield2 ; 



^' where "f ieldl" contains the first data field, which can be a data 

si 

Oname, system register, II - 18 or PI - P8 only, or a literal. 

Si 

FU Continuing, M field2" contains the second data fields, and the 
00 

contents of field2 are overlaid by the result of the AND opera- 
tion. Field2 can be a data name, a system register: II - 18 or 
PI - P8 only. 



As will be appreciated, the AND verb can be used to set a 
bit to 0. 

CLEAR 
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CLEAR verb sets one or more variables to null. The 
CLEAR statement may have either one or two operand. If only one 
operand is specified, it may contain the name of a field, an 
array or a data structure. If the operand contains a field name, 
then that field is set to null. If the operand contains an array 
name, then all elements of the array are set to null. If the 
operand contains the name of a data structure, then all fields 
and array elements in the data structure are set to null. If two 
operand are specified, then each operand must contain the name of 
a field. In this case, all fields, beginning with the field in 
operandi and ending with the field in operand2 , are set to null. 

yj The syntax for CLEAR is CLEAR namel [ , name2 ] ; where "namel" 

•nrs 

f£ contains the name of a field, array, or data structure to be set 

fZ to null. If "name2" is specified, namel must contain a field 

m 

^ name. Namel can be a data name, group data name, or system 
P register PI - P8 only. Further, name2 contains the last field 
RJ name of a range of fields to be set to null, and can be a data 
gg name, group data name, or system register PI - P8 only. 

W 

CLOSE 

The CLOSE verb is used to close a reception system file 
after file processing has been completed. By using CLOSE, the 
file named in operand 1 is closed. If no operand is specified, 
then all open files are closed. The CLOSE syntax is: 



CLOSE [filename]; 
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wher^^ "filename" contains the name of the reception system file 
to be closed. The file name "PRINTER" specifies the system 
printer. Otherwise, the name of the file must be a valid MS-DOS 
file specification; e.g., [drive: ] [\path\] name [ .extension] File 
name can be a data name, or system register PI - P8 only. When 
file processing is complete, the file must be closed. 

CLOSE_WINDOW 

The CLOSE_WINDOW verb is used to close the open window on 
the base screen and, optionally, open a new window by appending 
the partial operator _OPEN to the middle of the verb (as shown 

O below) . Specifically, by using CLOSE_WINDOW, open window on the 

SI 

hi base screen is closed. If no operand is specified, program 
m execution continues with the next statement in the program which 
l n last performed an OPEN_WINDOW. If operand 1 is specified, the 
^'window whose object ID is contained in operandi is opened, and 
£3 program execution continues with the first statement of the 
fy program associated with the newly opened window object. 

W 

The CLOSE_WINDOW syntax is: 

CLOSE_WINDOW [window-id] ; 

where, "window-id" contains the object ID of a new window to be 
opened after closing the currently open window. A window-id can 
be a data name, system register PI - P8 only, or a literal. 
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^^Lmilarly, the CLOSE_OPEN_WINDOW syntax, which causes a 
window to open upon the closing of the previous window, is: 

CLOSE_OPEN_WINDOW [window - id] 

The CLOSE_WINDOW verb can only be performed by a window 
program; i.e w a program associated with a window object* 
CLOSE_WINDOW is the method by which a window program relinquishes 
control. A window program can also close itself by performing 
one of the following verbs: NAVIGATE, TRIGGER_FUNCTION . Al- 
though a window program cannot perform a OPEN_WINDOW operation, 

Q it can use CLOSE_WINDOW to close itself and open another window. 

S! 

yj This process can continue through several windows. Finally, when 

25 . 

a window program performs a CLOSE_WINDOW without opening a new 

1^ 

[p window, program control does not work its way back through all 
^ the window programs. Instead, control returns to the non-window 
S program which opened the first window. Program execution contin- 
fU ues in that program with the statement following the OPEN_WINDOW 
fn statement. 

•ST1P 

CONNECT 

The CONNECT verb dials a telephone number. The telephone 
number contained in operand 1 is dialed. The telephone line 
status is returned in the system variable SYS_CONNECT_STATUS . 

The syntax for CONNECT is: 
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CONNECT phone_number; 

where "phone_number" contains the telephone number to be dialed. 
Phone_number can be a data name, system register PI - P8 only, or 
a literal. 

DEFINE_FIELD 

The DEFINE_FIELD verb is used to define a screen field at 
program execution time. From five to seven operand specify a 
single-line or multiple-line field within the currently active 
screen partition; i.e. the partition associated with the running 
program. The field is dynamically defined on the current screen 



yj partition. 



jyps The syntax for DEFINE_FIELD is: 



09 



DEFINE_FIELD name, row, column, width, height 



[,object_id [, state] ]; 



where "name 11 is the field to receive the name of a partition 
external variable. When this statement is performed, a screen 
field is defined and it is assigned to a partition external 
variable. The partition external variable name is placed in the 
name operand. Name may be a data name, or system register PI - 
P8 only. 
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^^ontinuing "row" in the DEFINE_FIELD syntax contains the row 
number where the field starts. The top row on the screen is row 
number 1. Row can be a data name, system register PI - P8, or a 
literal. "Column" contains the column number where the field 
starts. The leftmost column on the screen is column number 1. 
Column can be a data name, system register PI - P8 only, or a 
literal. In the DEFINE_FIELD syntax, "width" contains a number 
specifying how many characters each line the field will hold. 
Width can be a data name, system register PI - P8 only, or a 
literal. Further, "height" contains a number specifying how many 
lines the field will have. For multiple-line fields, each field 

□ line will begin in the column number specified in the column 

M 

Ly operand. Height can be a data name, system register PI - P8 
]5j only, or a literal. 

in 

8^ Yet further, in the DEFINE_FIELD syntax, "object_id" con- 

Q tains the object ID of a field post processor program that is to 

M 

|tf be associated with this field. Object_id can be a data name, 

88 

system register PI - P8 only, or a literal. Finally, for the 
DEFINE_FIELD syntax "state" contains a character string which is 
to be placed in parameter register PI when the program specified 
in the object_id operand is given control. State can be a data 
name, system register PI - P8 only, or a literal. 



In the case of the DEFINE_FIELD verb, if the object-id 
operand is specified, then the post processor program object is 
obtained only on a "commit" event; avoiding the need, for a 
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sync^^nous FETCH. Since DEFINE_FIELD defines a field only in 
the screen partition associated with the running program, a 
program can not define a field in some other screen partition 
with which it is not associated. Additionally, page-level 
processor programs which are not associated with a particular 
screen partition can not use this verb. 

DELETE 

DELETE is used to delete a reception system file for file 
processing. the file named in operand 1 is deleted. The syntax 
for DELETE is: 

Q 

SI 

DELETE [filename]; 



'where "filename" contains the name of the reception system file 
to be deleted. Filename can be a data name or system register PI 
p - P8 . Filename must be a valid operating specification. 

m 

m DISCONNECT 

The DISCONNECT verb "hangs up the telephone", thus, termi- 
nating the telephone connection. The syntax for DISCONNECT is 
simply: 



DISCONNECT; 



DIVIDE 
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^p^ie DIVIDE verb divides one number by another. The number 
in operand 2 is divided by the number in operand 1. The number 
in operand 1 is unchanged, however, the number in operand 2 is 
replaced by the quotient. If operand 3 is specified, the remain- 
der is placed in operand 3. The syntax for DIVIDE is: 

DIVIDE numberl , number2 [, remainder ] ; 



where "numberl" contains the divisor, i.e. the number to be 
divided into number2 . . Numberl can be a data name, system regis- 
ter, or literal number. Continuing, "number2" contains the 

p dividend; i.e., the number to be divided by numberl. The con- 

S! 

y tents of number2 are overlaid by the resulting quotient. Number2 

m 

2£ can be a data name, or a system register. And, "remainder" is a 

yj 

V variable or system register designated to hold the remainder of 
ff* the divide operation. Remainder can be a data name, or a system 

Si 

p register. 

M 



m TBOL will automatically perform data conversion when numberl 

,ftf? is not the same data type as number2 . Sometimes this will result 
in number2 having a different data type after the divide opera- 
tion. Fractions will be truncated after 13 decimal places, while 
whole number will not contain a decimal point. Negative results 
will contain a minus sign (-) in the left-most position. 

DO END 
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^^Le keyword DO specifies the beginning of a block of state- 
ments; the keyword END specifies the end of the block. A block 
of statements, bracketed by DO and END can be used as a clause in 
an IF or WHILE statement. In an IF statement, either the THEN 
clause or an optional ELSE clause can be executed, based upon the 
evaluation of a boolean expression. In a WHILE statement, the 
THEN clause is executed repetitively until a boolean expression 
is false. 

The syntax for DO... END is: 



O DO block. . .END; 



u 

OD 



f| where "Block" is any number of TBOL statements. As shown, the 

I** 

Ifi keyword DO is not followed by a semicolon, and the END statement 
requires a terminating semicolon. 



M 



Rj EDIT 

fjj The EDIT verb gathers and edits data from multiple sources, 

then joins it together and places it in the specified destination 
field. Data from one to six sources, beginning with operand 3, 
is edited in accordance with the mask contained inperand 2. The 
edited data, joined together as a single character string is 
places in the output destination field specified in operand 1. 



The EDIT syntax is EDIT output , mask , source [, source ...]; , 
where "output" contains the name of the destination field for the 



edi'^l data. After performance of the EDIT statement, the 
destination field will contain "sub-fields" of data; one for each 
source operand. Output can be a data name, or a register PI - P8 
only. 

Continuing, "mask" contains a character string consisting of 
one edit specification for each source operand. Edit specifica- 
tions are in the form: % [-] [min.max]x, where "%" indicates the 
beginning of an edit specification; "-" indicates left-adjustment 
of the source data in the destination sub-field, and "min.max" 
are two numbers, separated by a decimal point, which specify the 
p minimum and maximum width of the edited data in the destination 

h. 5 

igs sub-field, and "x" is an alpha character which controls the 

J| retrieval of data from the corresponding source operand. Fur- 
Ms 

* ther, "x" can be a "d" to indicate a digit, characters retrieved 

hi 

^" from the corresponding source operand are converted to integer 
D format; or "x" can be an "f" to indicate floating point, charac- 



py ters retrieved from the corresponding source operand are convert - 
GQ 

03 ed to a decimal format; or an "x" can be an "s" to indicate a 

€f 

string, characters retrieved from the corresponding source 
operand are converted to character format; or an "x" can be a "c" 
to indicate a character, only one character is retrieved from the 
corresponding source, operand, and is converted to character 
format . 
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^^laracters in mask which are not part of edit specifications 
are placed in output as literals. Mask can be a data name, or 
system register PI - P8 only. 

Continuous source contains the source data to be edited. 
The EDIT statement may contain up to six source operand. Mask 
must contain an edit specification for each source operand 
specified. Source can be a data name, a system register, or a 
literal . 

ENDPROC 

The END_PROC verb identifies the last physical statement in 
a procedure definition. Control returns to the "calling" proce- 
g dure and program execution continues with the statement following 
the "call" statement. The syntax for END_PROC is: 



m 



END_PROC ; 

An END_PROC statement is required as the last physical 
statement in every procedure. Accordingly, a procedure may 
contain only one END_PROC statement. 

An END_PROC statement in a "called" procedure is equivalent 
to a RETURN statement. Further, an END_PROC statement in the 
highest level procedure of a program is equivalent to an EXIT 
statement . 
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Exr 




The EXIT verb is used to transfer program control to the 
Reception System. When EXIT executes, the currently running 
program is ended. The data in operand 1 is moved to 
SYS_RETURN_CODE, and control is returned to the Reception System. 

The syntax for EXIT is: 



EXIT return-code ; 



where "return-code" contains data to be moved to SYS_RETURN_CODE 
p prior to transfer of control to the Reception System. A value of 

u 

00 



yyj 0 indicates a normal return. A non-zero value indicates an error 



condition. Return_code can be a data name, system register, or a 

ft literal . 
SJI 

on 

3 

O The EXIT verb is the normal way to end processing in a TBOL 

M 

pj program. In the highest level procedure of a program a RETURN or 

03 

man END PROC is equivalent to an EXIT. 

wV — 

. r=5t 

FETCH 

The FETCH verb is used to retrieve an object from a host 
system or from the Reception System storage device stage. The 
object specified in operand 1 is retrieved from its present 
location and made available in the Reception System. If operand 
2 is specified, the object's data segment is placed in the 
operand 2 field. 
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syntax for FETCH is: 
FETCH object_id [ , field] ; 

where "object_id" contains the object ID of the object to be 
located and retrieved. Object_id can be a data name, system 
register PI - P8 only, or a literal. 

In the FETCH syntax "field" contains t&e name of a field to 
hold the retrieved object's data segment. Field can be a data 
name, or a system register PI - P8 only. 



p When an object might be required for subsequent processing, 

i si the field operand should not be specified in the FETCH statement. 
Sin that case, the FETCH will be an asynchronous task and the 
^program will not experience a wait. The object is placed in the 

m 

^Reception System ready for use. The field operand is specified 
when an object is required to immediate use. Here, the FETCH is 



'WW 

SJ 



jflfa synchronous task and the program may experience a wait. When 

i 

I- 

'bject's data segment in the field operand. 



m 

f^the FETCH is completed, the program has access to the FETCHed o- 



FILL 

The FILL verb is used to duplicate a string of characters 
repeatedly within a field. The character string pattern con- 
tained in operand 2 is duplicated repeatedly in operand 1 until 
the length of operand 1 is equal to the number specified in 

i. 

operand 3. The syntax for FILL is: 
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FILL output , pattern, length; 



where "output" is the name of the field to be filled with the 
character string specified in "pattern". Output can be a data 
name or a system register PI - P8 only, or a literal. Finally, 
"length" contains an integer number specifying the final length 
of output. Length can be a data name, system register or a 
literal . 



FORMAT 

Q The FORMAT verb is used to transfer a string of character 

V| 

y data into variables defined in the DATA section of the program. 
2 The string of character data contained in operand 1 is trans- 

^ f erred to DATA section variables using destination and length 

IP 



specification in the format map contained in operand 2. The 



p FORMAT syntax is: 

Si 

m FORMAT source, map; 



where "source" contains a string of character data to be trans- 
ferred to DATA section variables, and can be a data name or 
system register PI - P8 only. 

Continuing, "map", on the other hand, contains a format map 
consisting of a destination/length specification for each field 
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of to be transferred. Map is created with the MAKE_FORMAT 

verb prior to execution of the statement. 



GOTO 

The GOTO verb transfers control to another statement within 
the currently running procedure. Program execution continues at 
the statement with the label identifier specified as operand 1. 
The syntax for GOTO is: 



U) 



GOTO label_id; 

where "label_id" is a label identifier directly preceding a 
statement within the currently running procedure. A GOTO state- 
SB ment can be used to transfer control to another procedure. 
CO 

N 8 Transfer to another procedure is accomplished by using the target 

m 

CH procedure name as the verb in a statement. 

P 

M 

n , GOTO_DEPENDING_ON 

2? The GOT DEPENDING ON verb transfers control to one of 

CO ~ 

*Q several other statements within the currently running procedure. 
Operand 1 contains a number, and is used as an index to select 
one of the label identifiers beginning with operand 2 in the 
statement. Program execution continues at the statement with the 
selected label identifier. 

The syntax for GOTO_DEPENDING_ON is: 
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GOT<j|^EPENDING_ON index, label_id [ , label_id. . . ] 



where "index" is an integer number used to select one of the 
label identifiers in the statement as the point where program 
execution will continue. If index contains a 1, then program 
execution continues at the statement with the label identifier 
specified as operand 2. If index contains a 2, then program 
execution continues at the statement with the label identifier 
specified as operand 3. And so on. If there is no label_id 

operand corresponding to the value in index, then program execu- 
tion continues with the statement following the GOTO_DEPENDING_ON 
p statement. Index can be a data name or system register. Contin- 
s/J uing, "label_id" is a label identifier directly preceding a 
^ statement within the currently running procedure. Up to 147 

label id operands may be specified in a GOTO_DEPENDING_ON state- 
yi 

01 ment . 

3 



A GOTO DEPENDING ON statement, however, cannot be used to 



S transfer control to another procedure. Transfer to another 
w 

r ^ procedure is done by using the target procedure name as the verb 
in a statement. 



IF THEN ELSE 

In this verb, the keyword IF directs the flow of program 
execution to one of two possible paths depending upon the evalua- 
tion of a boolean expression. The keyword IF is followed by a 
boolean expression. The boolean expression is always followed by 
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a T^^[ clause. The THEN clause may be followed by an ELSE 
clause. The boolean expression is evaluated to determine whether 
it is "true" or "false". If the expression is true, program 
execution continues with the THEN clause; the ELSE clause, if 
present, is- 

skipped. If the expression is false, the THEN clause is 
skipped; program execution continues with the statement following 
the clause or clauses. 



The syntax for IF. . .THEN. . .ELSE is: 



g IF boolean THEN clause [ELSE clause] ; 

w 

where "boolean" is a boolean expression. Boolean can be a single 
H relational expression or two or more relational expressions 

5 3*3 

OR separated by the key words AND and OR. These relational expres- 

Q sions can be enclosed with parentheses, and then treated as a 

Si 

ff\ single relational expression separated from others with AND or 



^ OR. They are evaluated from left to right, 



In the syntax, "clause" can be: a single statement, or a 
block of statements. Where clause is a block of statements, the 
block begins with the keyword DO and ends with the END verb. 
Further, Clause is always preceded by the keyword THEN or ELSE. 



INSTR 



-143- 



^^h e INSTR verb searches a character string to determine if a 
specific substring of characters is contained within it. The 
character string in operand 1 is searched for the first occur- 
rence of the character string in operand 2. If a matching string 
is found in operand 1, an integer number specifying its starting 
position is placed in operand 3. If a matching string is not 
found, 0 is placed in operand 3. 

The syntax for INSTR is: INSTR string , pattern , strt_pos ; 

INSTR string, pattern, strt_pos ; 

where "string" contains the character string to be 
W searched. String can be a data name, system register PI - P8 

m 

9 only, or a literal. 



09 



9 

b" Continuing, "pattern" contains the character string pattern 

£j which may occur within the string operand, and can be a data 
g-j? name, system register PI - P8 only, or a literal. 



Finally, "strt_pos" is the name of the variable where the 
starting position (or o) is to be stored. Strt_pos can be a data 
name, or system register PI - P8 only. 



LENGTH 

The LENGTH verb is used to determine the length of a speci- 
fied variable. An integer number specifying the number of 



-144- 



9 



• 



chai^^iers in operand 1 is placed in operand 2 . The syntax for 
LENGTH is: 

LENGTH field, length; 

where "field" contains the data whose length is to be determined. 
Field can be a data name, system register PI - P8 only, or a 
literal . 

Continuing, on the other hand, "length" is the name of the 
variable which is to contains the length of the field operand, 
O and can be a data name, or a system register PI - P8 only. 



m LINK 



m 



The LINK verb transfers control to another TBOL program. 
Program execution continues at the first statement in the program 

a 

S whose object ID is contained in operand 1. Up to eight parame- 
PJ ters may be passed to the "called" program in operand 2-9. 

09 

CO Control returns to the statement following the LINK statement 
when the "called" program performs an EXIT. 

The syntax for LINK is: 

LINK object__id [ , parameter. . . ] ; 

where "object_id" contains the object ID of a TBOL program, and 
can be data name, system register PI - P8 , only or a literal. 
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Furt^^r, "parameter" contains parameter data for the program 
whose object ID is contained in operand 1. The contents of the 
parameter operand 2 through 9, if present, are placed in parame- 
ter registers PI through P8. The number of parameter operand is 
placed in PO. PO through P8 are accessible to the "called" 
program. Parameter can be a data name, system register, or a 
literal . 

LOOKUP 

The LOOKUP verb issued to search for an entry in a table of 
data contained in a character string. Operand2 contains a single 

0 character string consisting of a number of logical records of 

SI 

W equal length. Each record consists of a fixed-length key field 
OS and a fixed-length data field. Operand 3 contains the record 
Ifl length. 

CP 

s 

ft 

Operand 1 contains a search key equal in length to the 
^ length of the key field. OPerand 2 in searched for a record with 
CO a key field equal to operand 1. If a record with a matching key 

y3 

is found, an integer number specifying its starting position is 
placed in operand 4. If a matching record is not found, 0 is 
placed in operand 4. 

The syntax for LOOKUP is: 

LOOKUP schkey , table , rcd_lth , result ; 
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whei^^ fl schkey" contains the key data of the desired record and 
can be a data name, system register or a litera. Further, 
"table" contains a character string consisting of a number of 
equal length logical records, and be a data name or system 
register PI - P8 only. Yet further, "red) 1th" contains an 
integer number equal to the length of a record in a table, and 
can be a data name, system register, or a literal. Finally, 
"result" is the name of the field to receive the result of the 
search. Result can be a data name, or a system register. 



MAKE_FORMAT 

P The MAKE FORMAT verb is used to create a format map for use 

M 

Ijj with the FORMAT verb. From 1 to 255 destination/length specif i- 
g cations contained in operands (beginning in operand 2) are used 
IH to create a format map which is stored in operand 1. Operand 1 
w " can then be specified as the map operand in a FORMAT statement. 

s 

G 

FU The MAKE FORMAT syntax is: 

err 

MAKE_FORMAT map, format [ , format. . . ] ; * 



where "map" is the name of the variable which is to contain the 
format map created with this statement. Map will be specified as 
an operand in a subsequent FORMAT statement to control the 
transfer of a string of character data to variables. Map can be 
either a data name or system register PI - P8 only. Continuing, 
"format" contains a destination/length specification for one 
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log^^l field of a string of character data. From 1 to 255 
format operands can be specified in this statement to create a 
format map. Each format operand controls the transfer of one 
logical field of data from a character string when the format map 
created in this statement is used in a subsequent FORMAT state- 
ment. In this arrangement, format can be a data name or a system 
register PI - P8 only. 



A destination/length specification in a format operand 
always contains a destination field name. The field name is 
followed by either one or two integer numbers controlling the 

P length of the designation field data. The field name and numbers 

M 

yj are separated by the colon character, e.g., destina- 
W 

tion: f ix_lth: imbed_lth, or destination: fix_lth, or as destina- 

ju. 

Ifi tion: : imbed 1th. 

V i 



For this approach, "destination is a variable field name 
fU which will contain the logical field of data from the character 

05 

(?) string after the subsequent performance of the FORMAT verb. And, 
^ M fix_lth M is an integer number between 1 and 33767 specifying a 
fixed field length for destination. If fix_lth is not specified 
then 2 colon characters are used to separate destination from 
imbed_lth, showing that fix_lth has been omitted. In this case, 
the destination field length is controlled entirely by imbed_lth, 
which must be specified. If fix_lth is specified and imbed_lth 
is not, then fix_lth characters will be transferred to destina- 
tion during the subsequent performance of the FORMAT verb. 
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Finc^^, if fix_lth is specified with imbed_lth, then destina- 
tion will have a length of fix_lth after the transfer of data by 
the FORMAT verb. 

Continuing, "imbed_lth" is an integer number, either 1 or 2 
which specifies length of an imbedded length field that immedi- 
ately precedes the logical field of data in the character string. 
The imbedded length field contains the length of the logical 
field of data immediately following. For example, 1 specifies a 
1-character length field and 2 specified a 2-character length 
field. 

0 
SI 

yj If imbed_lth is not specified then the designation field 

60 

Q3 length is controlled entirely by fix_lth, which must be speci- 
fy 

m fied. If imbed_lth is specified and fix_lth is not, then the 



• number of characters transferred to destination from the charac- 

a 

w ter string is controlled by the number in the one or two-charac- 

Sl 

PU ter length field which precedes the logical field of data. If 

w 

imbed_lth is specified with fix_lth, then the number of charac- 

SSL 

ters transferred to destination from the character string is 
controlled by the- 

number in the one or two-character length field which precedes 
the logical field of data. After the transfer of data, if the 
length of destination is not equal to fix_lth, then it is either 
truncated, or extended with blank characters as necessary. 

MOVE 
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^phe move verb copies data from one or more source fields 
into an equal number of destination fields. The data contained 
in the operand 1 data structure field (or fields) replaces the 
contents of the operand 2 data structure field (or fields) . 
Operand 1 data remains unchanged. Normally, the moved data is 
converted to the data type of the destination. If the key word 
ABS is included as operand 3, then data conversion does not take 
place. 

The syntax for MOVE is: 



O MOVE source, destination [ , ABS]; 

M 

U 

gg where "source" is the name of the data structure containing the 
UP data to be moved, and can be a data name, or a group data name, 
- or system register, or a literal. Further "destination" is the 

Si 

© name of the data structure field (or fields) to receive the 

■si 

fU source data, and can be a data name, or group data name, or a 

m 

system register. Finally, "ABS" is a keyword specifying an 
absolute move; i.e., no data conversion takes place. However, 
data residing in an integer register will always be in binary 
integer; and data residing in a decimal register will always be 
in internal decimal format. 



If the source operand is a group data name, then the desti- 
nation operand must be a group data name. Further, data in all 
of the fields contained in the source data structure or array are 
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mov^^to the corresponding fields in the destination data struc- 
ture or array. 



MULTIPLY 

The MULTIPLY verb multiplies two numbers. The number in 
operand 2 is multiplied by the number in operand 1. The number 
in operand 1 is unchanged. The number in operand 2 is replaced 
with the product of the two numbers. The syntax for MULTIPLY is: 



MULTIPLY number 1 , number 2 ; 



O where "numberl" contains the first number factor for the multiply 
M 

y operation, and can be a data name, system register or literal; 

00 

gg and l! number2" contains the second number factor for the multiply 
operation. Following execution, the contents of number2 are 
^ 5 overlaid with the resulting of the product. Number2 can be a 

G3 data name, or a system register. 

SI 

(ST 3 

60 

Jgj TBOL will automatically perform data conversion when numberl 

y3 

is not the same data type as number2 . Sometimes this will result 
in number2 having a different data type after the add operation. 
Fractions will be truncated after 13 decimal places, and whole 
numbers will not contain a decimal point. Negative results will 
contain a minus sign (-) in the left-most position. 



NAVIGATE 
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^£ie NAVIGATE verb is used to transfer control to the TBOL 
program logic associated with different page template objects. 
The external effect is the display of a new screen page. Operand 
1 contains either a page template object ID, or a keyword repre- 
senting a navigation target page. Control is returned to the 
Reception System where the necessary objects are acquired and 
made ready to continue the videotex session at the specified new 
page. 

The syntax for NAVIGATE is: 

P NAVIGATE object id; 

SI 

w 

.OS 

03 where Vobject_id" contains the object ID of a target page tern- 
|n plate object, and can be a data name, register PI - P8 only, or a 

Ms 

literal. 

m 

Q 

fU NOTE 

EO The NOTE verb returns the current position of the file 

pointer in a reception system file. Operand 1 contains the name 
of a file. An integer number specifying the current position of 
the file's pointer is returned in operand 2. The NOTE syntax is: 

NOTE filename , position ; 



where "filename" contains the name of a reception system file. 
The name of the file must be a valid MS-DOS file specification; 
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e.g^^[drive: ] [\path\]name[ .extension] . Filename can be a data 
name, or a system register PI - P8 only. Continuing, "position" 
is the name of the field to receive the current position of the 
file pointer for the file specified in filename. This will be an 
integer number equal to the numeric offset from the beginning of 
the file; a 10 in position means the file pointer is positioned 
at the 10th character position in the file. Position can be a 
data name, or system register. 



OPEN 

The OPEN verb is used to open a reception system file for 
£5 file processing. The file named in operand 1 is opened for 
y processing in the mode specified an operand 2. The syntax for 
qj OPEN is: 

5 5 

IP* 5 

m OPEN filename, INPUT : OUTPUT : I/O : APPEND : BINARY ; where 

O "filename" contains the name of the reception system file to be 
fU opened. As will be appreciated with this convention, the file 

09 

name PRINTER specified the system printer. Otherwise, the name 

5 

of the file must be a valid MS-DOS file specification; 
e.g. [drive: ] [ \path\] name [ . extension] . Filename can be a data 
name, or system register PI - P8 only. 

Further, "INPUT" is a keyword specifying that the file is to 
be opened for reading only; "OUTPUT" is a keyword specifying that 
the file is to be opened for writing only; "I/O" is a key word 
specifying that the file is to be opened for both reading and 
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wri"^^g; "APPEND" is a keyword specifying that the file is to be 
opened for writing, where new data is appended to existing data; 
and "BINARY" is a keyword specifying that the file is to be 
opened for both reading and writing. Where all file data is in 
binary format. 



OPEN_WINDOW 

The OPEN_WINDOW verb is used to open a window on the base 
screen. The window whose object ID is contained in operand 1 is 
opened. Program execution continues with the first statement of 
the program associated with the newly opened window object. The 
p syntax for OPEN_WINDOW is: 

I at 

fS OPEN WINDOW window id; 

in 

^ where "window_id" contains the object ID of the window to be 
O opened on the base screen, and can be a data name, or system 

fU register PI - P8 only or a literal . 

05 

'7- 

After performance of the OPEN_WINDOW statement, program 
execution continues with the first statement of the window 
program; i.e., the program associated with the newly opened 
window object. A window program relinquishes control by perform- 
ing a CLOSE_WINDOW. Although a window program cannot perform an 
OPEN_WINDOW, it can use CLOSE_WINDOW to close itself and open 
another window. This process can continue through several 
windows. Finally, when a window program performs a CLOSE_WINDOW 
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witj^pt opening a new window, program control does not work its 
way back through all the window programs. Instead, control 
returns to the non- window program which opened the first window. 
Program execution continues in that program with the statement 
following the OPEN_WINDOW statement. A window program can also 
close itself by performing one of the following verbs: NAVIGATE; 
or TRIGGER_FUNCTION. In such cases, control does not return to 
the program which opened the window. 

OR 

The OR verb performs a logical OR function on the bits of 
O two data fields. The logical sum (OR) of the bits of operand 1 

si 

yj and operand 2 is placed in operand 2. Moving from left to right, 

p =4 

the OR is applied to the corresponding bits of each field, bit by 
jjj bit, ending with the last bit of the shorter field. 



O If the corresponding bits are 1 and 1, then the result bit 

Si 

fU is 1. If the corresponding bits are 1 and 0, or 0 and 1, then 

CO 

pi the result bit is 1. If the corresponding bits are 0 and 0, then 
the result bit is 0. 



The data in operand 1 is left unchanged. The data in 
operand 2 is replaced by the result. 



The syntax for OR is: 



OR f ieldl, f ield2 ; 
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whei^^'f ieldl" contains the first data field, and can be a data 
name, or system register II - 18 or PI - P8 only, or a literal. 
Further, "field2" contains the second data field. The contents 
of field2 are overlaid by the result of the OR operation. Field2 
can be a data name, or system register II - 18 or PI - P8 only. 
As will be appreciated by those skilled in the art, the OR verb 
can be used to set a bit to 1. 

POINT 

The POINT verb is used to set the file pointer to a speci- 
fied position in a reception system file. Operand 1 contains the 
p name of a file. The file's pointer is set to the position 

Si 

yj specified by the integer number in operand 2. The POINT syntax 

m ls: 

m 

rfa POINT filename, position; 

few? 

N 

PJ where "filename" contains the name of a reception system file. 

©s 

« The name of the file must be a valid MS-DOS file specification; 
e.g. [drive: ] [\path\] name [ .extension] . File name can be a data 
name, or system register PI - P8 only. Further, "position" 
contains an integer number equal to the desired position of the 
file pointer for the file specified in filename. A 10 in posi- 
tion means the file pointer will be positioned at the 10th 
character position in the file. Position can be a data name, or 
system register or literal. 
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POP 




The POP verb transfers data from the top of the system stack 
to a variable field. The contents of operand 1 are replaced with 
data removed from the top of the system stack. The POP syntax 
is : 



POP field; 

where "field" is the name of the variable field to receive data 
from the stack, and can be a data name, or a system register. 



Q PUSH 

Q 

hi The PUSH verb transfers data from a variable field to the 

top of the system stack. The data contained in operand 1 is 

ft placed on the top of the system stack, "pushing down" the current 

111 

9^ contents of the stack. The contents of operand 1 remain un- 
O changed. The PUSH syntax is: 

ry 

S3 

m PUSH field; 



where "field" is the name of the variable field containing data 
to be "pushed" on the stack, and can be a data name, or a system 
register, or a literal. 



READ 

The READ verb is used to read data from a reception system 
file into a variable field. Operand 1 contains the name of a 
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fil^^ Data is read from the file, beginning with the character 
position specified by the current contents of the file's pointer. 
Data read from the file replaces the contents of operand 2. 
Operand 3 may be present, containing an integer number specifying 
the number of characters to be read. For ASCII files, data is 
read from the file until the first end-of-line character (ASCII 
13) is encountered. Or, if operand 3 is present, until the 
number of characters specified in operand 3 is read. For binary 
files, operand 3 is required to specify the length of the data to 
be read from the file. 

The syntax for READ is: 

READ filename, input [, length]; 



W 3 

V ? where "filename" contains the name of a reception system file, 
O which must be a valid MS-DOS file specification, e.g. 
pj [drive: ] [ \path\] name [ .extension] . Filename can be a data name, 

09 

m or system register PI - P8 only. Continuing, "input" is the name 

43 

of the variable field to receive data read from the file, and can 
be a data name, or a system register PI - P8 only. Finally, 
"length" contains an integer number. For ASCII files, length 
specifies the maximum number of characters to be read. For 
binary files, length specifies the length of the data to be read. 
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will be appreciated by those skilled in the art, in order 
to perform a READ operation, a file must first be opened as INPUT 
or I/O before the READ operation can take place. 

RECEIVE 

The RECEIVE verb is used to access the expected reply to a 
message sent previously to a host system. Operand 1 contains the 
message ID of a message sent previously to a host system. The 
message reply from the host replaces the contents of operand 2. 
The RECEIVE syntax is: 



p RECEIVE msg_is, message; 

si 
u 

m where "msg id" contains the ;message ID of a message sent previ- 
se 

ously to a host system, and can be a data name, or a system 

y s 

ff 1 register PI - P8 only. Further, "message" is the name of the 

fs 

O variable field to receive the incoming message reply, and can be 



a data name, or a system register PI - P8 only. 



- RELEASE 

The RELEASE verb reclaims memory space in the reception 
system by deleting a block of data saved previously with the SAVE 
verb. The block of data named in operand 1 is deleted from 
memory . 

The syntax for RELEASE is: 
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C LEASE block_name; 

where "block_name" contains a block name used in some previously 
performed SAVE statement , and can be a literal. 

RESTORE 

The RESTORE verb is used to restore the previously saved 
contents of a block of variables. The block of data named in 
operand 1 replaces the contents of a block of variables, begin- 
ning with the variable named in operand 2. The RESTORE syntax 
is : 

o 

Vi 

RESTORE block_name, f ieldl; 



m 

Ijj where "block_name" contains a block name used in some previously 

yi performed SAVE statement, and can be a literal. Further, 

£3 "f ieldl" is the name of the first field or a data structure to 
SI 

fU receive data from the block specified in block_name. Fieldl can 



S3 be a data name, or a group data name. 
RETURN 

The RETURN verb is used to return control to the procedure 
which "called" the currently running procedure. Execution of the 
currently running procedure is ended. The data in operand 1 is 
moved to SYS_RETURN_CODE , and control is returned to the proce- 
dure which "called" the currently running procedure. 
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^^ie RETURN syntax is: 
RETURN return-code; 



where "return-code" contains data to be moved to SYS_RETURN_CODE 
prior to transfer of control to the "calling" procedure, and can 
be a data name, or system register, or a literal. It should be 
noted that in the highest level procedure of a program, a RETURN 
or an END_PROC is equivalent to an EXIT. 



SAVE 

Q The SAVE verb is used to save the contents of a block of 

S! 

yj variables. Operand 1 contains a name to be assigned to the block 

£Q 

of saved data. This name will be used later to restore the data. 

ft : 

TZ If operand 2 is specified without operand 3, then operand 2 may 

Hi 
ffi 

- contain the name of a field, an array, or a data structure. In 

O this case, the contents of the field; or the contents of all the 

St 

fy elements in the array; or the contents of all the fields in the 
fg data structure are saved under the name specified in operand 1. 
If operand 2 and operand 3 are specified, then they both must 
contain a field name. In this case, the contents of all the 
fields, beginning with the field in operand 1 and ending with the 
field in operand 2, are saved under the name specified in operand 
1. 



The syntax for SAVE is: 



^^AVE block_name , namel [ , name2 ] ; 

where "blockjiame" contains a block name to be assigned to the 
saved data, and will be used subsequently to restore the saved 
contents of the fields* Block_name can be a data name, system 
register PI - P8 only, or a literal. Continuing, "namel" contains 
the name of a field, array, or data structure to be saved. If 
name2 is specified, namel must contain a field name. Namel can 
be a data name. Further, "name2" contains the last field name of 
a range of fields to be saved, and it can be a data name. 

SEND 

The SEND verb is used to transmit a message to a host 
system.- The message text contained in operand 2 is transmitted 
from the reception system using a message header constructed from 
the data contained in operand 2. Operand 3, if present, indi- 
cates that an incoming response to the message is expected. The 
syntax for SEND is: 

SEND message [, RESPONSE : TIMEOUT] ; 

where "message" contains the outgoing message text (the header 
data for which has been placed in GEVs before SEND) , and can be a 
data- name, or a system register, or a literal. "RESPONSE" is a 
keyword indicating that a response to the message is expected. 
"TIMEOUT" is a parameter that sets the number of seconds for 
message time-out. 
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^^fter performance of the SEND statement, the global external 
system variable SYS_LAST_MSG_ID contains a message ID number 
assigned to the outgoing message by the Reception System, This 
message ID number can be used later in a RECEIVE statement. 

SET^ATTRIBUTE 

The SET_ATTRI BUTE verb is used to set or change the color 
and input format attributes of a screen field. The characteris- 
tics of the screen field expressed as operand 1 are set or 
changed according to the specifications contained in operand 2. 
The syntax for SET_ATTRI BUTE is: 

o 

M 

jyg SET_ATTRIBUTE name, attr_list; 

CO 

^ where "name" expresses the name of the field whose characteris- 
^ tics are to be set or changed. This is a partition external 

Br 

O variable name, and if the name is expressed as a literal; e.g., 
RJ "SET_ATTRIBUTE 1,...", then this is taken to mean that the 
attributes of the partition external variable &1 contains the 
name of the partition external variable whose attributes are to 
be set by this statement. 

Further, n attr_list" is a literal character string contain- 
ing a list of key words and values describing the desired at- 
tributes to be assigned to the field expressed in operand 1. 
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^ppien SET_ATTRIBUTE is performed, existing field attributes 
remain in effect unless superseded by the attribute list con- 
tained in operand 2. 

The attribute list operand literal is in the form: ' key- 
word [ (values) ] [ , keyword [ (values) ]...]' 

It should also be noted that where key words and their 

associated values are: "DISPLAY" , not user input data can be 

entered in a field with this attribute; 11 INPUT" , a field with 

this attribute can receive user input data; "ALPHABETIC", an 

□ INPUT field with this attribute can receive any alphabetic 
N 

y character: A through A, and blank; "ALPHANUMERIC", an "INPUT", 

05 

m field with this attribute can receive any displayable character; 

w 

N* .... 

l& "NUMERIC", an INPUT field with this attribute can receive any 

^ numeric character: 0 through 9, ( $ ), ( , ), ( • ), and ( - ); 

Q "PASSWORD", an INPUT field with this attribute is intended for 

py use as a password field. Any character entered by the user is 

QS 

^displayed in the field as an asterisk ( * ); "ACTION", a field 

■J3 

~ with this attribute is a TBOL "action" field; "COLOR ( fg , bg) " , 
where fg and bg are numeric values specifying the foreground and 
background colors of the field; "FORM (pattern) " , where pattern 
specifies the input data format for this field. Pattern may 
contain "A", an alphabetic character of A through Z, which must 
be in this position; "a", an alphabetic character of A through Z, 
or a blank, which must be in this position; "N" a number charac- 
ter of 0 through 9, or ($),(,),(.), or ( - ) which must 
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be i^^his position; "n", a numeric character of 0 through 9, or 
( $ ) , ( , ) , ( . ) , ( - ) , or a blank may occupy this position; 
"X", any displayable character which must be in this position; 
and "x" , any displayable character or a blank which must be in 
this position. 

Any other character in the pattern is displayed in the field 
as a literal, and acts as an autoskip character at user input 
time* To include any of the pattern characters as literals in 
the pattern, they must be preceded by the backslash character. 
For example, to include the character "A: as a literal in a 
pattern it would code as "\A" . To include the backslash charac- 

W 



a ter as a litera, it would code as "\\" 



ft SET CURSOR 

Ml ~~ 

Ifl The sET_CURSOR verb moves the cursor to the field specified 

in 

Was operand 1, itself specified as a field number. The syntax for 

SI 

HJ the SET_CURSOR verb is: 

£Q 

08 



SET_CURSOR [field number] 
SET_FUNCTION 

The SET_FUNCTION verb changes and/or filters a "logical 
function 11 process program. The syntax for SET_FUNCTION is: 
SET_FUNCTION function_id, status [ , program__ob j ect_id [ , state] ] ; 
where 11 f unction_id__ is the logical function" identifier; "status" 
is one of the following key words: "DISABLE"; "FILTER"; or 
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"EN£^p" . DISABLE is used to de-activate "logical function". 
FILTER is used to execute the logic contained in pro- 
gram_object_id prior to executing the normal "logical function" 
process. It the logic contained in program_object_id returns a 
non-zero SYS_RETURN_CODE< the normal "logical function" process 
will not execute, otherwise, it begins. ENABLE is used to set 
"logical function" to normal default process. 

Continuing, in the SET_FUNCTION syntax, "program_object_id" 
is the 13 byte object_id of the TBOL program, (conditional) ; and 
"state" is data to be passed to the "logical function" program. 

O The data will reside in the PI register when logic is executed, 

SI 

yj (optional) . 



03 

SORT 

^ The SORT verb is used to sort a range of variable fields 

P into the sequence of the key contained in each field. Each 

fU variable field contains a record consisting of a fixed-length key 

W 

m field followed by a data field. The key field is the same length 
is each record. Operand 1 contains the name of the first field 
in the range of fields to be sorted; operand 2 contains the name 
of the last field. Operand 3 contains an integer number specify- 
ing the length of the key field contained in the beginning of 
each field. The fields in the range specified by operand 1 and 
operand 2 are sorted into the sequence of the key field. 



The syntax for SORT is: 
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SORT fieldl,field2,key__lath; 



where "fieldl" contains the first field name of the range of 
fields to be sorter, and can be a data name, or system register 
PI - P8 only; "field2" contains the last field name of the range 
of fields to be sorted and can be a data name; or system register 
PI - P8 only; and fl key_lath" contains an integer number equal to 
the length of the key field contained in each field in the range. 
Key_lath can be a data name, or system register PI - P8 only or a 
literal . 



p SOUND 

pj The SOUND verb is used to produce a sound through the 

03 

reception system speaker. A sound is produced of the pitch 
\ m specified by operand 1, for the duration specified by operand 2, 
%# s if operand 1 and operand 2 are not present, values from the most 
P recently performed SOUND statement are used. The SOUND syntax 

fU is: 

S3 



^0 

SOUND [pitch, duration] ; 



where "pitch 11 is a numeric value in the range of 0 to 20,000 
specifying the desired pitch of the sound. Pitch can be a data 
name, system register PI - P8 , or a literal; and "duration" is a 
numeric value in the range of 0 to 65,535 specifying the desired 
duration of the sound in increments of .1 seconds. Duration can 
be a data name, or system register PI - P8 only or literal. 
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STRl^p) 

The STRING verb joins multiple character strings together 
with into one character string. Up to eight character strings, 
beginning with the character string contained in operand 1, are 
joined together sequentially. The resulting new character string 
replaces the contents of operand 1. The STRING syntax is: 

STRING stringl, [, string. ..] ; 

where "stringl" is empty, or contains the character string which 

will become the left-most portion of the new character string, 

O and a data name, or a system register PI - P8 only; "string" is 
M 

yj empty, or contains the character string to be joined behind the 

65 

Cg character strings in preceding operands, and can be a data name, 
ILp or system register PI - P8 only or a literal. 

m 

O SUBSTR 

fU The SUBSTR verb is used to copy a substring of characters 

GO 

£Q from a character string into a designated variable field. The 
character string containing the substring is in operand 1. 
Operand 3 contains an integer number equal to the position of the 
first character to be copied. Operand 4 contains an integer 
number equal to the number of characters to be copied. The 
specified substring is copied from the character string in 
operand 1 and replaces the contents of operand 2 . 



The syntax for SUBSTR is: 
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^ppBSTR str ing,destinat ion , strt_pos, length; 



where "string" contains a character string, and can be a data 
name or system register PI - P8 only, or a literal; "destina- 
tion" is the name of the variable field to receive the substring 
copied from the string operand, and can be a data name, or system 
register PI - P8 only, "strt,pos" contains an integer number 
specifying the position of the first character to be copied into 
the destination operand, and can be a data name, or system 
register or a literal; and "length" contains an integer number 
specifying the number of characters to be copied into the desti- 

Q nation operand, and can be a data name, or system register or a 

l*) literal. 

m 

U 

jjs! In accordance with this arrangement, the SUBSTR operation 

u '' does not take place if: if the length operand is 0, or if the 
p; strt_pos operand is greater than the length of the string oper- 
ry and. 



SUBTRACT 

The SUBTRACT verb subtracts one number from another. The 
number in operand 1 is subtracted from the number in operand 2 . 
The number in operand 1 is unchanged. The number in operand 2 is 
replaced by the arithmetic difference between the two numbers. 
The syntax for SUBTRACT is: 



SUBTRACT numberl , number2 ; 
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whe3^^" number 1" contains the number to be subtracted from num- 
ber2, and can be a data name, or system register, or a literal; 
"number2" contains the second number- As noted, the contents of 
number2 are overlaid with the resulting difference. Number2 can 
be a data name, or system register. 

TBOL will automatically perform data conversion when numberl 
is not the same data type as number 2 . Sometimes this will result 
in number2 having a different data type after the subtract 
operation- Fractions will be truncated after 13 decimal places, 
and whole numbers will not contain a decimal point. Further, 

£3 negative results will contain a minus sign (-) in the left-most 

S3 

yj position. 



in 

y " TRANSFER 

35 

if 55 *! 



1 1 



The TRANSFER verb transfers control to another TBOL program. 

FU Control however, does not return to the original program. 
00 

Rather, program execution continues at the first statement in the 

re. ' 

program whose object ID is contained in operand 1. Up to eight 
parameters may be passed to the "called" program in operands 2 - 
9. Control is transferred to the Reception System when the 
"called" program performs an EXIT. 



The syntax for TRANSFER is: 



TRANSFER ob j ect_id [ , parameter. . . ] ; 
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whe^Jh"object_id" contains the object ID of a TBOL program, and 
can be a data name, or system register PI - P8 only, or a liter- 
al; "parameter" contains parameter data for the program whose 
object ID is contained in operand 1. The contents of the parame- 
ter operands 2 through 9, if present, are placed in parameter 
registers PI through P8 . The number of parameter operands is 
placed in PO. PO through P8 are accessible to the "called" 
program. Parameter can be a data name, or system register, or a 
literal . 



TRI GGER_FUNCTI ON 

p The TRIGGER_FUNCTION verb is designed to execute a "logical 

yj function" . Its syntax is: TRIGGER_FUNCTION functioned; where 
jjp "function_id" is the logical function" identifier. In accordance 
^ with the design of TRIGGER. FUNCTION, control may or may not be 
ff* returned depending on the function requested. 

3 

m UPPERCASE 

The UPPERCASE verb converts lowercase alphabetic characters 
to uppercase alphabetic characters. Lowercase alphabetic charac- 
ters (a - z) in the character string contained in operand 1 are 
converted to uppercase alphabetic characters (A - Z) . The syntax 
for UPPERCASE is: 



UPPERCASE string; where "string" contains a character 
string, and can be a data name, or a system register PI - P8 
only. 
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WAI 




The WAIT verb causes program control to be given to the 
REception System for the number of seconds defined in the parame- 
ter head. Control is given to the Reception System for one "time 
slice" and then returned to the currently running program. 



The WAIT syntax is simply: 



WAIT /seconds 
WHILE THEN 

Q The key word WHEN causes a single statement or a block of 

SI 

y statements to be executed repetitively while a specified boolean 
ipg expression is true. The key word WHILE is followed by a boolean 
U expression. The boolean expression is always followed by a THEN 
^ s clause. The boolean expression is evaluated to determine whether 
Hit is "true" or "false". If the expression is true, the THEN 
fu clause is executed and the expression is evaluated again. If the 

00 

fQ expression is false, program execution continues with the stat- 
ement following the THEN clause. 



The syntax for WHILE... THEN is: 



WHILE boolean THEN clause; 



where "boolean is a boolean expression, which can be a single 
relational expression, where a relational expression consists of 
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twa^J^erands separated by a relational operator such as ( = ) , 
(<>) / (<) / (>) / (<-) f or (">) * or two or more relational expres- 
sions separated by the key words AND or OR. These relational 
expressions can be enclosed with parentheses, and then treated as 
a single relational expression separated from others with and or 
OR. Further, they are evaluated from left to right. Continu- 
ing, with the syntax for WHILE. THEN, "clause" can be either a 
single statement, a block of statements, where the block begins 
with the key word GO and ends with the END verb. 



When character strings of unequal length are compared 
p lexicographically, the longer string is truncated to the length 
tsj of the shorter string before the comparison. If the shorter 
^string compares "high", then the longer string is "lower". For 

ft example: When comparing "GG" to "H" , "GG" is valued as less 

III 

0^than"H". If the shorter string compares "low" or "equal", then 

'£., 

P the longer string is "high". For example: When comparing "TO" to 

M 

fy "TOO", "TO" is less than "TOO". 

09 
00 

^ In this regard, truncation is done outside of the operands, 

which the operands remaining the same length after the evalua- 
tion. 



WRITE 

WRITE is the verb used to write records to a file. The 
syntax for WRITE is: 
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^^RITE filename , output_area [, key] 



where "filename" is the name of the file that the record is to be 
written to, and can be a field_id, array^id (subscript) , parti- 
tion_external_id, global_external_id, or a literal; "output_area" 
is the name of the area from which the record will be created, 
and can be a field_id, array_id (subscript) , partition_external_id 
or a global_external_id; and "length" specifies either the 
maximum number of characters to be read from an ASCII file, or 
the length of data to be read from a binary file. The file must 
have been previously opened as OUTPUT, APPEND, or I/O. 



t3 

SA 

It - 



m GLOBAL EXTERNAL SYSTEM VARIABLES 

J In accordance with the design of TBOL, names have been 

-~ assigned to the TBOL system variables in the global external 
O variable (GEV) data structure. The names of GEVs are assigned in 
fU DEFINE statements as described above and in the file TBOL. SYS. 

bp 

g There are a total of 32,000 GEVs. The first 256 GEVs are re- 

t~5Jl 

served for the system, and the remaining 31,744 are assigned as 
application variables, and are application-specific. Since 

system variables referenced by TBOL interpreter as global 

variables and are ascii strings, a system variable table is 
constructed so that reception system native code can access them 
as binary integer. An adaptation of this table from the source 
code file "\rs\rsk\c\sysvar .c" is shown in Table 1. 
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TABLE 1 

SYSTEM GLOBAL EXTERNAL VARIABLES 



System Variable Name 



GEV# 



Description / 



Sys_rtn_code ; 

Sys_api_event; 

or sel/ Sys_logical_key ; 



/ 0001 API instr. return code./ 
/ 0002 API event: post , pre , init 
/ 0003 Current logical key. 





/ Sys_last_msg_id; 




/ 0004 


Last 


message id. / 


M 

y 


Sys_tone_pulse ; 


/ 


0005 


Phone type pulse/tone. / 


i 


Sys_line_status ; 


/ 


0006 


Line connection status. / 




Sys_keyword ; 


/ 


0007 


Keyword 


flag. / 


pi 


Sys_automat ic_uppercase ; 


/ 


0008 


Auto 


uppercase. / 


n 

•srsr 


Sy s_scr ol l_incr ement ; 


/ 


0009 


Scroll 


increment. / 


SI 


Sys_current_f ield; 


/ 


0010 


Current 


field. / 


00 
CO 


Sys_date; 


/ 


0011 


system 


date. / Sys_time; 


J5 


/ 0012 system time. / 


Sys_current_page ; 


/ 0013 



current page. / Sys_selected_ob j_id ; 



/ 0014 sel object 



id. / Sys_navigate_obj_id; 

Sys_cur sor__row ; 

Sys_cursor_col ; 

Sys_path ; 

/ Sys_ttx_jphone ; 

Sys_total_pages ; 



/ 0015 nav object id. / 

/ 0016 cursor row position. / 

/ 0017 cursor col position. / 

/ 0018 user personal path table. 

/ 0019 dial trintex phone #. / 

/ 0020 total pages in page set. 
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/ 0026 



/ s^^page_number ; 

/ Sys_base_obj_id; 
id . / Sys_window_id ; 
object-id. / Sys__path_ptr ; 
location. / Sys_keywords ; 
Sys_current_cursor_pos ; 
Sy s_current_background_col or ; / 0027 
Sys_current_f oreground_color ; / 0028 
Sys_hardware_status ; / 0029 

Sys_nocomin; / 003 0 

Sys_um__dia_header ; / 0031 

msg. / Sys_um_message_text ; 



/ 0021 Curr. page of of n pages. 
/ 0022 curr. base page object- 
/ 002 3 Curr. window 
/ 0024 Curr. path 

/ 0025 Keyword list. / 
Curr. cursor position. / 
Curr background color. / 
Curr foreground color. / 
nature of hard error. / 
send: don't send to SI. / 
header for unsolicited 
/ 0032 text for unsolicited 



00 



In 



SI 

m 

OP 
09 



msg. / Sys_ca_error_track_info; / 0033 error tracking data. 

/ Sys_assisant_current_inf o ; / 0034 curr. context info. / 
Sys_screen_data__table ; / 0035 data table for copy and 



file. / Sys_ad_list; / 0036 

list. / Sys_current_keyword ; / 0037 

current keyword. / Sys_jprevious_keyword; 
Pointer to previous keyword. / Sys_guide; 
003 9 Guide. / Sys_previous_menu; 

menu object- id. / Sys_previous_seen_menu; 
seen menu obj-id. / Sys_scan_list ; 
Pointer to scan list. / Sys_scan_list_pointer ; 
User scan list pointer. / Sys_path_name ; 
Pointer to path name. / Sys_navigate_keyword ; 
Navigate to keyword. / Sys_keyword_table ; 



Pointer to AD 



Pointer 
/ 0038 



to 



/ 



/ 0040 
// 0041 
/ 0042 

/ 0043 

/ 0044 
/ 0045 
/ 0046 



Prev 
Prev 
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Sys J ^^yword_disp ; 

Sys_keyword_table_entry_length ; / 0048 
Sys_keyword_length; / 0049 

Sys_ext_table; / 0050 



/ 



0047 



Sys_data_col 1 ect 



/ 0051 Indicates Tracking status 

/ 52 / DIA message header Sys_fmO_txdid; 



Sys_f m0_txhdr ; 

/ 53 



id 
OS 

m 
m 



/ 11 Sy s_f m0_txr id ; 

Sy s_f m4_txhdr ; 
Sys__f m4_txuseid ; 
/ 57 / Sys_fm64_txhdr; 

Sys_f m64_txdata ; 
/ 60 / Sys_fm4_rxhdr ; 

Sys_fm4_rxuseid ; 
/ 63 / Sys_fm64_rxhdr ; 

Sys_f m64_rxdata ; 
/ 66 , md/ Sys_leave; 

Sys_return ; 

md,area for 



/ 54 



/ 69 
/ 70 
/ 71 



/ 55 

/ 56 

/ 59 

/ 62 

/ 65 

/ 68 



/ 
/ 

/ 

/ 

/ 



/ 



Sys_f m4_txcorid ; 



/ 58 



/ 61 



/ 64 



/ 



Sys_f m0_rxhdr ; 

/ 

Sys_f m4_rxcor id ; 
/ 



Sys_surrogate ; 
/ 67 , md/ 

md/ Sys_int_regs ; 



int save stack/ Sys__ttx_help_id ; 



md,id of system help window/ Sys_selector_data ; 



md / Sys selector path; 
Sys_logical_event ; / 7 3 

/ 74 , mg/ Sys_help_appl ; 

Sys_help_hub_appl_pto ; / 76 

Sys_access_key_obj__id ; / 7 7 

/ 78 , Sys__messaging_status ; 

/ 80 , Sys_leader_ad_id; 

Sys_baud__rate ; / 82, 
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/ 72 , md/ 

, am/ Sys_user_id; 

/ 75 , md/ 

md/ 

, lw , bi/ Sys_word_wrap=l ; 

/ 79 , Sys_version; 

/ 81 
Sys_com_port ; 



/ Sys_obj_header ; 

Sys_session_status ; / 85, 

/ NA Defne system variable 



H 



m 



m 
m 



n 
M 

s 



INTLEN , S YS_INT_TYPE , 

INTLEN , S YS_INT_TYPE , 

INTLEN , S YS_INT_TYPE , 

INTLEN , SYS_INT_TYPE , 

INTLEN , S YS_INT_TYPE , 

INTLEN , SYS_INT_TYPE , 

INTLEN , S YS_INT_TYPE , 

INTLEN , SYS_INT_TYPE , 

INTLEN , SYS_INT_TYPE , 

INTLEN, SYS_INT_TYPE, & (unsigned int) Sys_date 
SYS_STR_TYPE, & (unsigned int) Sys_time, 



/ 84, 

Systbl sys_var_table [ ] = 
table . &Sys_rtn_code , 

&Sys_api_event , 
&Sy s_logical_key , 
&Sys_last_msg_id , 
&Sys_tone_jpulse , 
&Sys_line_status , 
&Sys_keyword , 
&Sys_automat ic__uppercase , 
&Sys_scroll_increment , 
&Sys_current_f ield , 

0, 
0, 



SYS_STR_TYPE, 
SYS_INT_TYPE, 
SYS_STR_TYPE, 
SYS_STR_TYPE, 
SYS_INT_TYPE , 
SYS_INT_TYPE, 
SYS_STR_TYPE, 
SYS_STR_TYPE, 
SYS_INT_TYPE, 
SYS_INT_TYPE, 
SYS_STR_TYPE, 
SYS_STR_TYPE, 
SYS_INTJTYPE , 



&Sys_current_page, 0, 

& (unsigned int) Sys_selected_obj_id, 0 , 

& (unsigned int) Sys_navigate_obj_id, 0 , 

&Sys_cursor_row , 0 , 

&Sys_cursor_col , 0 , 

& (unsigned int) Sys_path, 0, 

& ( uns igned int ) Sy s_ttx_phone , 0 , 

&Sys_total_pages , INTLEN , 

&Sy s_page_number , INTLEN , 

& (unsigned int) Sys_base_obj__id , 0, 

& (unsigned int) Sys_window_id, 0, 

&Sys_path_ptr , INTLEN , 

& (unsigned int) Sys_keywords , 0, 
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TYPE, 


&Sys_current 


_cursor_pos, 


INTLEN, 




SYS_INT_ 


TYPE , 


&Sys_current_ 


_background_color , 


INTLEN, 




SYS_INT_ 


TYPE , 


&Sys_current 


_f oreground_color , 


INTLEN , 




SYS_INT_ 


TYPE , 


&Sys__hardware_status , 


INTLEN, 




SYS_INT_ 


TYPE, 


&Sys nocoiroti , 




INTLEN, 




SYS_INT_ 


TYPE, 


& (unsigned 


int) Sys_um_dia_header , 


o, 




SYS_STR_ 


TYPE , 


ot \ unsigned 


int) Sys__um_message_text , 


o, 




SYS_STR_ 


TYPE, 


ot \ unsiyneu 


int) Sys_ca_error_track_inf o , 0 , 




SYS_STR_ 


TYPE, 


a (unsignea 


int) Sys_assisant_current_inf o 0 , 




SYS_STR_ 


TYPE, 


& (unsigned 


lntj oys screen aciuci uo.jj.lc2, 






SYS_STR_ 


TYPE , 


& (unsigned 


lnu ; oys au list. , 


n 


U 


SYS_STR_ 


_TYPE, 


& (unsigned 


inuj oys c_» u. i. i ti 1 1 l, jvey wuiu ^ 




- E 
-~J 


SYS_STR_ 


_TYPE , 


& (unsigned 


-5 \ Qvre riTPvi nil ^ kpvunTri 
xi i u j o_y& pi.cvj.uua jvey wuxu ; 


o 


yj 


SYS_STR_ 


TYPE , 


f\ / n -y^ « T i-Q 

ot [unsignea 


int) Sys_guide , 


o, 


E s 


SYS_STR_ 


_TYPE, 


ot (unsigneu 


int) Sys_jprevious_menu, 


o, 


SYS_STR_ 


TYPE, 


ot (unsignea 


int) Sys_previous_seen_menu, 


o, 




SYS_STR_ 


TYPE , 


ot ^unsiynea 


int) Sys_scan_list , 


o, 


HI 

e 


SYS_STR_ 


_TYPE , 


Of ^ UilbXgilcU 


int) Sys_scan_list_pointer , 


o, 




SYS_STR_ 


_TYPE , 


& (unsigned 


int) Sys_path_name , 


o, 




SYS_STR_ 


_TYPE , 


& (unsigned 


int) Sys_navigate_keyword , 


o, 




SYS_STR_ 


_TYPE, 


& (unsigned 


int) Sys_keyword_table , 


o, 




SYS_STR_ 


_TYPE , 


& S y s_k ey wo rd_ 


disp, 


INTLEN , 




SYS_INT_ 


_TYPE , 


& S y s_keywo r d_ 


table_entry_length , 


INTLEN, 




SYS_INT_ 


TYPE , 


& S y s_key wo r d 


^length, 


INTLEN, 




SYS_INT_ 


TYPE , 


& (unsigned 


int) Sys_ext_table, 


o, 



SYS_STR_TYPE, & ( ) Sys_data_collect , & (unsigned int) Sys_f m0_txhdr , 
0 , SYS_STR_TYPE, & (unsigned int) Sys_fm0_txdid, 0 , 







TYPE , 


& (unsigned int) 


Sys_f mO_txr id , 


0, 




SYS_STR_ 


TYPE , 


& ( uns igned int ) Sy s_f m4_txhdr , 


0, 




SYS_STR_ 


TYPE, 


& ( uns igned int ) 


Sy s_f m4_txuse id , 


0, 




SYS_STR_ 


TYPE , 


& (unsigned int) Sys_fm4_txcorid , 


0, 




SYS_STR_ 


TYPE , 


& (unsigned int) Sys__fm64_txhdr , 


0, 




SYS_STR_ 


TYPE , 


& ( uns igned int ) 


Sys__f m64_txdata , 


0, 




SYS_STR_ 


TYPE , 


& (unsigned int) Sys_fmO_rxhdr , 


0, 




SYS_STR_ 


TYPE , 


& (unsigned int) 


Sy s_f m4_rxhdr , 


0, 




SYS_STR_ 


TYPE , 


& (unsigned int) 


Sys_f m4_rxuseid , 


0, 




SYS_STR_ 


TYPE , 


& ( uns igned int ) 


Sys_f m4_rxcor id , 


0, 




SYS_STR_ 


TYPE , 


& ( uns igned int ) 


Sys_f in64_rxhdr , 


o, 


Q 


SYS_STR_ 


TYPE , 


& ( uns igned int ) 


Sys_f m64_rxdata , 


o, 


w 


SYS_STR_ 


TYPE , 


&Sys_surrogate , 




INTLEN, 


ffl 


SYS_INT_ 


TYPE , 


& ( uns igned int ) 


Sys_leave, 


o, 


m 


SYS_STR_ 


_TYPE , 


& (unsigned int) 


Sy s_return , 


o, 


pi 


SYS_STR_ 


TYPE , 


& (unsigned int) 


Sys_mt_regs , 


o, 


pi 

-par 


SYS_STR_ 


TYPE , 


& ( uns igned int ) 


Sys_ttx_help_id , 


o, 


JJ! 


SYS_STR_ 


TYPE , 


& (unsigned int) 


Sys_selector_data , 


o, 




SYS_STR_ 


_TYPE , 


fit (unsigned int) 


Sys_selector_path , 


o, 




SYS_STR_ 


_TYPE , 


&Sy s_logical_event , 




INTLEN, 




SYS_INT_ 


_TYPE , 


& (unsigned int) 


Sys_user_id , 


o, 




SYS_STR^ 


TYPE , 


&Sys_help_appl , 




INTLEN, 




SYS_INT_ 


TYPE , 


& (unsigned int) 


Sys_help_hub_appl_pto , 


o, 




SYS_STR_ 


JTYPE, 


& (unsigned int) 


Sys_access_key_ob j_id , 


o, 




SYS_STR_ 


_TYPE , 


&Sys_word_wrap , 




1, 




SYS_INT_ 


_TYPE , 


& (unsigned int) Sys_messaging_status , 


o, 




SYS_STR_ 


_TYPE , 


& (unsigned int) 


Sys_version, 


o, 
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SYS^pCRJTYPE , 

SYS_STRJTYPE, 
SYS_INT_TYPE , 
SYS_INT_TYPE, 
S YS_STR_TYPE , /RDC 
INTLEN , S YS_INT_TYPE , 



& (unsigned int) Sys_leader_ad_id, 0, 

&Sys_baud_rate , INTLEN , 

&Sys_com_port , INTLEN , 

&Sys_obj_header , 0, 



&Sys_session_status , 



m 
m 



-181- 



Table 2 



TBOL VERBS BY FUNCTIONAL CATEGORY 



DATA PROCESSING 

MAKE_FORMAT 
SUBSTR CLEAR 
OR 
EDIT 
FILL 
n FORMAT 



INSTR 



W LENGTH 



m PROGRAM FLOW 



LOOKUP 
STRING AND 

MULTIPLY 

UPPERCASE 
POP 
PUSH 
RELEASE 
RESTORE 



SORT ADD 

MOVE 
SUBTRACT DIVIDE 

SAVE 
XOR 



m 

m 



CLOSE WINDOW 



ERROR 



■*f EXIT 
GOTO 

GOTO_DEPENDING_ON 
IF. . .THEN. . .ELSE 



NAVIGATE 

OPEN_WINDOW 

RETURN 

SET FUNCTION 



SYNC_RE LEASE 
TRANSFER 
TRIGGER_FUNCTION 
WAIT 

WHILE... THEN LINK 



COMMUN I CAT IONS 



CONNECT 



RECEIVE 
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DISCONNECT 

FILE MANAGEMENT CLOSE 

NOTE 

OPEN 

POINT 



READ 
SEND 
WRITE 



SCREEN MANAGEMENT 



DEFINE FIELD 



OBJECT MANAGEMENT 



Lpl FETCH 

R PROGRAM STRUCTURE 

M 



SET_ATTRIBUTE 
SET _CURSOR 
SOUND 



REFRESH FILE SCREEN 



DO. . .END 



END PROC 
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RECEPTION SYSTEM OPERATION 



RS 4 00 of computer system network 10 uses software called 
native code modules (to be described below) to enable the user to 
select options and functions presented on the monitor of personal 
computer 405, to execute partitioned applications and to process 
user created events, enabling the partitioned application to 
interact with interactive system 10. Through this interaction, 
the user is able to input data into fields provided as part of 
the display, or may individually select choices causing a stan- 
dard or personalized page to be built (as explained below) for 
display on the monitor of personal computer 405. Such inputs 

R will cause RS 400 to interpret events and trigger pre-processors 

% ! 

^ or post-processors, retrieve specified objects, communicate with 

OS 

63 system components, control user options, cause the display of 
U1 advertisements on a page, open or close window partitions to 

m 

$ provide additional navigation possibilities, and collect and 

Q 

report data about events, including certain types of objects 
J^L processed. For example, the user may select a particular option, 
S3 such as opening or closing window partition 275, which is present 
on the monitor and follow the selection with a completion * key- 
stroke, such as ENTER. When the completion keystroke is made, 
the selection is translated into a logical event that triggers 
the execution of a post-processor, (i.e., a partitioned applica- 
tion program object) to process the contents of the field. 

Functions supporting the user-partitioned application 
interface can be performed using the command bar 290, or its 
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equ^^lent using pull down windows or an overlapping cascade of 
windows. These functions can be implemented as part of the RS 
native functions or can be treated as another partition (s) 
defined for every page for which an appropriate set of supporting 
objects exist and remain resident at RS 4 00. If the functions 
are part of RS 4 00, they can be altered or extended by verbs 
defined in the RS virtual machine that permit the execution of 
program objects to be triggered when certain functions are 
called, providing maximum flexibility. 

To explain the functions the use of a command bar is as- 

Ssumed. The command bar 290 is shown in Figures 3(a) and 3(b) 

Nf 

jW includes a NEXT command 291, a BACK command 292, a PATH command 
£0 293, a MENU command 294, and ACTION command 295, a JUMP command 
IH2 96, a HELP command 2 97, and an EXIT command 2 98. 

"01 

H NEXT command 291 causes the next page in the current pageset 

p to be built. If the last page of a pageset has already been 
00 reached, NEXT command 291 is disabled by RS 400, avoiding the 
presentation of an invalid option. 

BACK command 292 causes the previous page of the current 
pageset to be built. If the present page is the first in the 
pageset, BACK command 292 is disabled, since it is not a valid 
option. 
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filter program can be attached to both the NEXT or BACK 
functions to modify their implicit sequential nature based upon 
the value of the occurrence in the object set id. 

PATH command 292 causes the next page to be built and 
displayed from a list of pages that the user has entered, start- 
ing from the fist entry for every new session. [p29] 

MENU command 294 causes the page presenting the previous set 
of choices to be rebuilt. 

ACTION command 295 initiates an application dependent 

W operation such as causing a new application partition to be 

CO 

interpreted, a window partition 275 to be opened and enables the 

M* 

Ul user to input any information required which may result in a 

cn 

a transaction or selection of another window or page. 

a « 
H. S 

LJ[ JUMP command 2 96 causes window partition 27 5 to be opened, 

f "§ allowing the user to input a JUMPWORD or to specify one from an 
index that may be selected for display. 

HELP command 297 causes a new application partition to be 
interpreted such as a HELP window partaining to where the cursor 
is positioned to be displayed in order to assist the user regard- 
ing the present page, a particular partition, or a field in a 
page element. 
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^^XIT command 298 causes a LOGOFF PTO to be built. 



NAVIGATION INTERFACE 

Continuing, as a further feature, the method aspect of the 

invention includes an improved procedure for searching and 

retrieving applications from the store of applications distribut- 
ed 

throughout network 10; e.g., server 205, cache/concentrator 302 
and 

the RS 400 units, as described above. More specifically, the 

^ procedure features techniques for reducing the demand on the 
server 

tu 

C8 205 for searching, and retrieving applications for display at 
CO 

M* monitor 414 by using pre-created search tables which represent 

m 

fll subsets of the information on the network identified by page 

m 

f*j template objects and object ids so that in accordance with the 

=»1 procedure, the tables and associated objects can then be provided 

I v 

^ to and searched at the requesting RS 4 00, thus relieving server 
205 from that responsibility. 

In conventional time-sharing networks that support large 
In conventional databases, the host receives user 

requests for a data records; locating them; and transmitting them 
back to the users. Accordingly, the host is obliged to undertake 
the data processing responsibility necessary to provide the 
information, and, as noted earlier, where large numbers of users 
are to be served, the many user requests may bottleneck at the 
host, taxing resources and leading to response slowdown. 
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^^urther, users have experienced difficulty in searching data 

bases maintained on conventional time-sharing networks. For 

example, difficulties have resulted from the complex and varied 
way 

previously known database suppliers have organized and presented 

their information. Particularly, some database providers require 

searching be done only in selected fields of the data base, thus 

requiring the user to be fully familiar with the record struc- 
ture. 

Others have organized their databases on hierarchial structures 

which require the user understand the way the records are 
grouped . 

p Still further, yet other database suppliers rely upon keyword 
"^indices to facilitate searching of their records, thus requiring 

m 

65 the user to be knowledgeable regarding the particular keywords 
03 used 

U1 by the database provider. 

M ! 

~ The method aspect of the present invention, however, serves 

if 535 ! 

iTj to avoid such difficulties. In the preferred embodiment, the 
method aspect of the present invention includes procedures for 

W creating preliminary searches which represent subsets of the 

network applications that the users are believed likely to 

investigate. Particularly, in accordance with these procedures, 

for the active applications available on network 10, a library of 

tables is prepared, within each of which the tables a plurality 
of 

so called " JUMPwords" are provided that are correlated with page 

template objects and object ids associated with respective 
network 

applications. In the preferred embodiment, approximately 1,000 
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tab^fc are uses, each having approximately 10 to 2 0 jumpwords 

to abstract the applications on the network. Further, each table 

is associated with a code in the form of a character string 

mnemonic so that on entry of a character string at an RS 400, an 

appropriate table will be selected at server 205, which repre- 
sents 

a subset of the objects and associated applications on the 
network, 

and that table will then be presented to the user's RS 4 00, where 

the RS 4 00 can provide the data processing required to present 
the 

potentially relevant jumpwords, objects and associated applica- 
tions 

O 

^ to the user for further review and determination as to whether 

B 3 £ 

CO more searching is required. This relieves the demand on server 

CO 2 05 

||f and thereby permits it to be less complex and costly, and fur- 
£?! ther, 

n reduces the likelihood of overtaxing that may reduce network 
^ response time. 



W As a further feature of this procedure, the library of 



*J3 



jumpwords and their associated PTOs may be generated by a plural- 
ity 

of operation which appear at the user's screen as different 
search 

techniques. This permits the user to select a search technique 
he 

is most comfortable with, to thereby expedite his inquiry. 

More particularly, in accordance with the invention, the 

user 

is allowed to evoke the procedure by calling up a variety of 
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opei^^Lon. The various operations have different names and 

seemingly present different search strategies to the user. 

Specifically, the user may initiate the procedure by invoking a 

so called "Jump" operation with the selection of a Jump command 
at 

RS 400. Thereafter, when prompted, the user may enter a word of 

the user's choosing at screen 414 relating to the matter he is 

interested in locating; i.e., a subject matter search of the 

network applications. Additionally, the users my evoke the 

procedure by alternatively calling up an operation termed "Index" 

by selecting the Index command, which command in response 
presents 



^ the user with an alphabetical listing of jumpwords from which the 
W user can select; i.e., an alphabetical search of the network 

ihrk 

CO applications. Further, the user may evoke the procedure by 

|H initiating an operation termed "Guide" by selecting that command, 

y - 

~ which, thereafter, provides the user with a series of graphic 

displays that presents a physical description of the network 

^applications; e.g., department floor plan for a store the user 
W may 

63 

be electronically shopping in. Still further, the user may evoke 

the procedures by initiating an operation termed "Directory" by 

selection of that command, which then presents the applications 

available on the network as a series of hierarchial menus which 

categorically arrange the content of the network information. 

In accordance with the invention, this ability to convert 

these apparently different search strategies in a single proce- 
dure 

for accessing pre-created library tables is accomplished by 
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trar^^ting the procedural elements of the different search 

techniques by means of a conversion table into a single set of 

procedures that will produce a mnemonic which can be used to 
select 

the appropriate library table and associated jumpwords, PTO and 

object ids. Thus, while the search techniques may appear differ- 
ent 

to the user, and in fact accommodate the user's preferences and 
sophistication level, they nonetheless evoke the same efficient 
procedure of relying upon pre-created searches which identify 
related application PTOs and object ids so that the table and 
objects may be collected and presented at the user's RS 4 00 where 
G they can be processed, thus relieving server 205. 

W A more detailed understanding of the procedure may be had 

CO upon 



m a reading of the following description and review of accompanying 

m 

g\ Fig. 11 which presents a flow diagram of the search procedure. 



* To select a particular partitioned application from among 

ly 

* . * 

w thousands of such applications residing either at the RS 400 or 
09 

y3 within delivery system 20, the present invention avoids the need 
for a user to know or understand, prior to a search, the organ- 
ization of such partitioned applications and the query techniques 
necessary to access them. This is accomplished using a collec- 
tion of related commands, as described below. 



The JUMP command 296, a flowchart for the execution of which 
is shown in Figure, is selected by the user from command bar 29 0, 
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whic^^selection causes window partition 275 to open. At this 
point, the user may, in the preferred embodiment, select from a 
variety of options displayed on the monitor of personal computer 
in window partition 275. Among these options, the user may 
either select a DIRECTORY command, an INDEX command, a GUIDE 
command, or input into display field 270 within window partition 
275 a "best guess" of the mneumonic character string that is 
assigned to a desired partitioned application (e.g., the user may 
input such english words as "news," "pet food," "games," etcet- 
era) . The JUMP command 296 will be discussed first, as it is 
related to and supports user learning in combination with the 
^ INDEX command and the DIRECTORY command , in ways that will 
^ become clear through discussion of the operation of the JUMP 

5 

09 command 296. 

in 

(U c 

s The character string entered by the user in display field 

® 270 of JUMP command 296 window partition 275 is searched by RS 

^ 400 native code (discussed below) against tables of keywords (not 

13 

shown) that RS 4 00 requests from high function host 210. High 
function host 210 maintains a list of unique alphanumeric strings 
13 character for PTOs and their associated PTOid's. The tables 
requested from high function host 210 are constructed by search- 
ing for keywords using the first characters of the string entered 
by the user, until a table of keywords within an arbitrary range 
of the first characters of the string is produced (in the pre- 
ferred embodiment, considerations of line speed and usage have 
dictated that the table be 12 keywords) . The table of keywords 

-192- 



giv^pbhe closest approximations to the character string entered 
by the user. The table is then sent to RS 4 00 as message data. 



If the string entered by the user is a unique keyword 
existing in the table of keywords, and is thus associated with a 
specific PTO, RS 400 fetches and displays the partitioned appli- 
cations that are to be processed and built according to the page 
composition dictated by the target PTO as processed by the native 
code. 

If the string entered by the user does not specify a unique 

IT 3 ** 

H PTO, RS 4 00 presents the user with the option to display the 

W table of keywords as initialized, cursorable selector fields in 

08 

OB an INDEX page. The user may then move the cursor to the nearest 
LT! approximation of the nmeuonic he originally selected, and trigger 

m 

- navigation to the PTO associated with that keyword (by, in the 
Sri preferred embodiment, pressing the "Return" key) . Navigation is 
*J* executed as described in the section of this specification 
00 entitled "RS NATIVE CODE." 

If, instead of invoking the JUMP command 296, the user 
instead selects the INDEX command , the RS 4 00 will retrieve the 
keyword table residing in either the cache or stage of the local 
store 472, and will again build a page with initialized, 
cursorable fields of keywords. The table fetched upon invoking 
the INDEX command will be comprised of alphabetic keywords that 
occur within an arbitrary range of the keywords associated with 
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the^^TO from which the user invoked the INDEX command . As 
discussed above, the user may select to navigate to any of this 
range of PTOs through selecting the relevant keyword from the 
display. 

The DIRECTORY command will cause RS 4 00 to fetch from 
interactive system 10 a table of keywords, grouped by subject, to 
which the PTO of the current partitioned application (as speci- 
fied by the object set field 630 of the current PEO ) belongs. 
The RS 4 00 displays to the user these keywords together with 
descriptive statements about the application associated with the 
!pj keywords. The user who can, in the manner previously discussed 

W with regard to the INDEX command , select from and navigate to 

CO 

CS the PTOs of keywords which are related to the present pageset by 
HI subject. 

y * 

s 

The GUIDE command provides a navigation method related to a 
^ hierarchical orgainzation of applications which are described in 
a series of menus. Such menus, which use overlaying windows of 
subject areas, are well known to the art, and are expressed in a 
different manner in, for example, software for the Apple 
Macintosh. The GUIDE command makes use of the keyword segment 
which describes the location of the PTO in a hierarchy (referred 
to, in the preferred embodiment, as the "BFD," or Building-Flo- 
or-Department) as well as the JUMPword character string. The BFD 
describes the set of menus that should be displayed in windows on 
the screen in a series of pop-up menus. GUIDE command may be 
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invo^pj by requesting such from a menu presented to the user, or 
by selecting the MENU command when the stack of PTOid's for MENU 
is empty. 



The PATH command is a list of user pre-selected keywords 
that may be presented to user by electing the VIEWpath command. 
As in the INDEX command the PATH command presents the 
pre-selected keywords as initialized, cursorable fields, which 
the user may select from using the tab and return keys on the 
keyboard of the personal computer. 



^ Collectively, the JUMP command 296, the INDEX command , the 

W DIRECTORY command , the GUIDE command , and the PATH command 
CO enable the user to quickly and easily ascertain the "location" of 
Iff either the partitioned application presently displayed or the 
s "location" of a desired partitioned application. "Location," as 
^ used in reference to the preferred embodiment of the invention, 
means the specific relationships that a particular partitioned 
68 application bears to other such applications, and the method for 
selecting particular partitioned applications from such relation- 
ships. The techniques for querying a database of objects, 
embodied in the present invention, is an advance over the prior 
art, insofar as no foreknowledge of either database structure or 
query technique or syntax is necessary. The structure and search 
techniques are made manifest to the user in his use of the above 
commands. 
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RS APPLICATION PROTOCOL 



RS protocol defines the way the RS supports user - applica- 
tion conversation (input and output) and the way RS 4 00 processes 
a partitioned application. Partitioned applications are con- 
structed knowing that this protocol will be supported unless 
modified by the application. The protocol is illustrated FIG. 6. 
The boxes in FIG. 6 identify processing states that the RS passes 
through and the arrows indicate the transitions permitted between 
the various states and are annotated with the reason for the 
^ transitxon. 

Si 
W 

60 The various states are: (A) Initialize RS , (B) Process 

N" 

Ljf| Objects, (C) Interpretively Execute Pre-processors, (D) Wait for 

a" Event, (E) Process Event, and (F) Interpretively Execute Function 

O 

£j Extension and/or Post-processors. 

03 The transitions between states are: (la) Logon PTO-id, (lb) 

Object-id, (2) Trigger PDO-id & return, (3) PPT or Window Stack 
Processing complete, (4) Event occurrence, and (5) Trigger PDO-id 
and return. 

Transition (la) from Initialize RS (A) to Process Objects 
(B) occurs when an initialization routine passes the object-id of 
the logon PTO to object interpreter 43 5, when the service is 
first invoked. Transition (lb) from Process Event (E) to Process 
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Obj^^ (B) occurs whenever a navigation class event causes a new 
PTO object-id to be passed to object interpreter 4 35; or when a 
open window event (verb or function key) occurs passing a window 
Object-id to the object interpreter 4 35; or a close window event 
(verb or function key) occurs causing the current topmost window 
to be closed. 

While in the process object state, object interpreter 435 
will request any objects that are identified by external refer- 
ences in call segments. Objects are processed by parsing and 
interpreting the object and its segments according to the specif- 

Oic object architecture. As object interpreter 4 35 processes 

M 

Wobjects, it builds a linked list structure called a Page Process- 
Sing Table (PPT) , shown in figure 10, to reflect the structure of 
[fjjthe page, each page partition, PEOs required, Program Data 
^Objects (PDOs) required and each window object that could be 

Hcalled. Object interpreter 435 requests all objects required to 

Sj 

fU build a page except objects that could be called as the result of 
09 

BSsome event, such as a HELP window object. 

Transition (2) from Process Objects (B) to Interpretively 
Execute Pre-processors (C) occurs when the object interpreter 4 35 

determines that a pre-processor is to be triggered. Object 
processor 4 58 then passes the object-id of the (PDO) to the TBOL 
interpreter 438. TBOL interpreter 438 uses the RS virtual 
machine to interpretively execute the PDO. The PDO can represent 

-197- 



eit^p a selector or an initializer. When execution is complete, 
a transition automatically occurs back to Process Objects (B) . 



Selectors are used to dynamically link and load other 
objects such as PEOs or other PDOs based upon parameters that 
they are passed when they are called. Such parameters are 
specified in call segments or selector segments. This feature 
enables RS 400 to conditionally deliver information to the user 
base upon pre-determined parameters, such as his personal demo- 
graphics or locale. For example, the parameters specified may be 
the transaction codes required to retrieve the the user's age, 

Osex, and personal interest codes from records contained in user 

SI 

W profiles stored at the switch/file server layer 200. 
00 

Uj Initializers are used to set up the application processing 

^environment for a partitioned application and determine what 

^ events RS 400 may respond to and what the action will be. 

SJ 

fy 
09 

00 Transition (3) from Process Objects (B) to Wait for Event 

(D) occurs when object interpreter 435 is finished processing 
objects associated with the page currently being built or opening 
or closing a window on a page. In the Wait for Event state (D) , 
input manager accepts user inputs. All keystrokes are mapped 
from their physical codes to logical keystrokes by the Keyboard 
Manager 434, representing keystrokes recognized by the RS virtual 
machine. 
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^^7hen the cursor is located in a field of a page element, 
keystrokes are mapped to the field and the PEV specified in the 
PEO field definition segment by the cooperative action of input 
manager 452 and display manager 461. Certain inputs, such as 
RETURN or mouse clicks in particular fields, are mapped to 
logical events by keyboard manager 434, which are called comple- 
tion (or commit) events. Completion events signify the comple- 
tion of some selection or specification process associated with 
the partitioned application and trigger a partition level and/or 
page level post-processor to process the "action" parameters 
associated with the user's selection and commit event. 



O 



yj Such parameters are associated with each possible choice or 

(35 input, and are set up by the earlier interpretive execution of an 
J initializer pre-processor in state (C) . Parameters usually 
"specify actions to perform a calculation such as the balance due 
H on an order of several items with various prices using sales tax 
for the user's location, navigate to PTO-id, open window WO-id or 
^ close window. Actions parameters that involve the specification 
of a page or window object will result in transition (lb) to the 
Process Objects (B) state after the post-processor 1 is invoked as 
explained below. / 



Function keys are used to specify one or more functions 
which are called when the user strikes these keys. Function keys 
can include the occurrence of logical events, as explained above. 
Additionally, certain functions may be "filtered", that is, 
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exte^^id or altered by SET_FUNCTION or TRIGGER_FUNCTION verbs 
recognized by the RS virtual machine. Function keys cause the 
PDO specified as a parameter of the verb to be interpretively 
executed whenever that function is called. Applications use this 
technique to modify or extend the functions provided by the RS . 

Transition (5) from Process Event (E) to Interpretively 

Execute Pre-processors (F) occurs when Process Event State 

determines that a post-processor or function extension PDO is to 

be triggered. The object-id of the PDO is then passed to the id 

of the Program Data Object (PDO) to the TBOL interpreter 438. 

SjThe TBOL interpreter 438 uses the RS virtual machine to interpre- 

Wtively execute the PDO. When execution is complete a transition 

©automatically occurs back to Process Event (E) . 
¥* 

m 

RECEPTION SYSTEM SOFTWARE 

P 
SI 

The reception system 400 software is the interface between 

OP 

09 the user of personal computer 405 and interactive network 10. 
The object of reception system software are to minimize mainframe 
processing, minimize transmission across the network, and support 
application extendability and portability. 

RS 4 00 software is composed of several layers, as shown in 
FIG. 7: (1) external software 450, which is composed of elements 
well known to the art and beyond the scope of the present inven- 
tion, such as device drivers, the native operating systems (such 

-200- 




as and MAC Toolbox), machine-specific assembler functions (in 

the preferred embodiment, for example, CRC checking) , and "C" 

runtime library functions; (2) native software 4 20; and (3) 
partitioned applications 410. 

Again with reference to FIG. 7, native software 42 0 is 
compiled from the "C" language into a target machine-specific 
executable, and is composed of two components: the service 
software 430 and 431 and the operating environment 450. Operat- 
ing environment 450 is comprised of the Logical Operating System 
432, or LOS; and a multitasker 433. Service software 430 and 431 
□provides functions specific to providing interaction between the 

yjuser and interactive network 10, while the operating environment 

S3 

gf|4 50 provides pseudo multitasking and access to local physical 
^resources in support of service software 430 and 431. Both 
^layers of native software 420 contain kernal, or device indepen- 

S3 

Cjdent functions 430 and 432, and machine-specific or device 
fUdependent functions 431 and 433. All device-dependencies are in 

00 

fgjcode resident at RS 400, and are limited to implementing only 
those functions that are not common across machine types, to 
enable interactive network 10 to provide a single data stream to 
all makes of personal computer. Source code for the native 
software accompanies this specification and provides a detailed 
teaching of the art concerning the claims directed toward the 
software comprising this invention. 
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^^rvice software 430 and 431 is comprised of modules, which 
are device-independent software components that together obtain, 
interpret and store partitioned applications existing as a 
collection of objects. The functions performed by, and the 
relationship between, the service software 430 and 431 modules 
are described in FIG. 8 and discussed further below. 



Through facilities provided by LOS 432 and multitasker 433, 
here called collectively operating environment 450, provides 
device-independent multitasking and access to local machine 
resources, such as multitasking, timers, buffer management, 
® dynamic memory management, file storage and access, keyboard and 
^mouse input, and printer output. The operating environment 450 

m 

CS manages communication and synchronization of service software 4 30 

{Hand 431, by supporting a request/ response protocol and managing 

CP 

B the interface between the native software 420 and external 

Q 

tVsof tware 437. 

S3 Applications software layer 410 consists of programs and 

data written in an interpretive language, "TRINTEX Basic Object 
Language" or "TBOL, " which was written specifically for use in RS 
400 and interactive network 10 to facilitate videotex-specific 
commands and achieve machine-independent compiling. TBOL is the 
current preferred embodiment for this invention. TBOL is con- 
structed as objects, which in interaction with one another 
comprise partitioned applications, and is disclosed at length 
elsewhere in this document. 
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native software provides a virtual machine interface for 
partitioned applications, such that all objects comprising 
partitioned applications "see" the same machine. RS native 
software provides support for the following functions: (1) 
keyboard and mouse input; (2) text and graphics display; (3) 
application interpretation; (4) application database management; 
(5) local application storage; (6) network and link level commu- 
nications; (7) user activity data collection; and (8) advertise- 
ment management. 



With reference to FIG. 8, service software 4 30 and 431 is 

©comprised of the following modules: (1) startup; (2) keyboard 

SI 

iy manger 4 34 ; (3) object interpreter 4 35 ; (4) TBOL interpreter 

C0 438; (5) object storage facility 439; (6) display manager 461; 

01(7) data collection manager 466; (8) ad manager 432 ; (9) ob- 

J ject/communications manager interface 433; (10) link communica- 

^tions manager 444; and (11) fatal error manager 469. Each of 

^ these modules has responsibility for managing a different aspect 
00 

of RS 400. 

tost 



Startup reads RS 400 customization options into RAM, includ- 
ing modem, device driver and telephone number options, from the 
file CONFIG. SM. Startup invokes all RS 4 00 component startup 
functions, including navigation to the first page, a logon screen 
display containing fields initialized to accept the user's id and 
password. Startup is not shown in FIG. 8. 
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^^he principal function of keyboard manger 4 34 is to trans- 
late personal computer dependent physical input into a consistent 
set of logical keys and to invoke processors associated With 
these keys. Depending on the LOS key, and the associated func- 
tion attached to it, navigation, opening of windows, and initia- 
tion of filter or post-processor TBOL programs may occur as the 
result input events handled by the keyboard manger 434. In 
addition, keyboard manger 434 determines inter- and intra-field 
cursor movement, and coordinates the display of field text and 
cursors entered by the user with display manager 4 61, and sends 
information regarding such inputs to data collection manager 466. 

O 

y Object interpreter 435 is responsible for building and 

03 recursively processing a table called the "Page Processing 

\p Table," or PPT. Object interpreter 435 also manages the opening 
ffi 

™~ and closing of windows at the current page. Object interpreter 
0 4 35 is implemented as two subcomponents: the object processor 4 36 



fU and object scanner 437 



43 



Object processor 4 36 provides an interface to keyboard 
manger 4 34 for navigation to new pages, and for opening and 
closing windows in the current page. Object processor 43 6 makes 
a request to Object storage facility 439 for a PTO or WEO, as 
requested by keyboard manger 434, and for objects and their 
segments which comprise the PTO or WEO returned by Object storage 
facility 439 to object processor 436. Based on the particular 
segments comprising the object (s) making up the new PTO or WEO, 
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obj^^ processor 436 builds or adds to the PPT, which is an 
internal, linked-list, global data structure reflecting the 
structure of the page or PFO, each page partition or PEO, and 
Program Data Objects (PDOs) required and each window object that 
could be called. Objects are processed by parsing and interpret- 
ing each object and its segment (s) according to their particular 
structure as formalized in the DOA. While in the process object 
state, object processor 436 will request any objects specified by 
the PTO that are identified by external references in call 
segments (e.g. field level program call 518, page element selec- 
tor call 524, page format call 526 program call 532, page element 

p call 522 segments) of such objects, and will, through a request 
SI 

yj to TBOL interpreter 438, fire initializers and selectors con- 
fix tained in program data segments of all PTO constituent program 

La 

in objects, at the page, element, and field levels. Object proces- 
^ sor 435 requests all objects required to build a page, except 

O objects that could only be called as the result of some event 

SI 

ftf external to the current partitioned application, such as a HELP 
window object. When in the course of building or adding to the 
PPT and opening/closing WEOs, object processor encounters a call 
to an object with object-id "ADS LOT , " it fetches the next adver- 
tisement object 510 from ad manager 432, and sends to display 
manager 461 for display to the user presentation data segments 
530 contained in the objects constituent of the PTO, WEO and 
advertisement object. Object processor also passes to data 
collection manager 466 all object-ids that were requested and 
object-ids that were viewed. Upon completion of page or window 
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proa^^ing, object processor 436 enters the wait for event state, 
and control is returned to keyboard manger 434. 

The second component of object interpreter 4 35, object 
scanner 437, provides a file-like interface, shared with object 
storage facility 439, to objects currently in use at RS 400, to 
enable object processor 4 36 to maintain and update the PPT* 
Through facilities provided by object scanner 437, object proces- 
sor recursively constructs a page or window in the requested or 
current partitioned application, respectively. 

Object storage facility provides an interface through which 



*~ object interpreter 435 and TBOL interpreter 4 38 either synchro- 

w 

3 nously request (using the TBOL verb operator "GET") objects 
U1 without which processing in either module cannot continue, or 

m 

5 asynchronously request (using the TBOL verb operator "FETCH") 

fi 

objects in anticipation of later use. Object storage facility 
^4 39 returns the requested objects to the requesting module once 
^ retrieved from either local store 440 or interactive network 10. 
Through control structures shared with the object scanner 4 37, 
object storage facility determines whether the requested object 
resides locally, and if not, makes an attempt to obtain it from 
interactive network 10 through interaction with link communica- 
tions manager 444 via object/communications manager interface 
433 . 
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^^ien objects are requested from object storage facility 4 39, 
it must always provide the latest version of the object to 
guarantee currency of information to the user. Object storage 
facility 439 does this by requesting objects that are not locally 
available and by requesting version verification from network 10 
for those objects which are available locally. 



Version verification increases response time. Therefore, 
not all objects locally available are version checked each time 
they are requested. Typically, objects are checked only the 
first time they are requested during a user session. 

w 

W The frequency with which the currency of objects is checked 

CO- 
OS depends on factors such as the frequency of updating of the 

H 

0! objects. For example, objects that are designated as ultrastable 
a ' in a storage control parameter in the header of the object are 
h. i never version checked unless a special version control object 
jjj sent to the RS as part of logon indicates that all such objects 
vU must be version checked. Object storage facility 439 marks all 
object entries with such a stability category in all directories 
indicating that they must be version checked the next time they 
are requested. 



Object storage facility 439 manages objects locally in local 
store 440, comprised of a cache (segmented between available RAM 
and a fixed size disk file) , and stage (fixed size disk file) . 
Cached objects are retained only during user sessions, while 
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stag^^ objects are retained between sessions. The storage 
control field, located in the header portion of an object, 
indicates whether the object is stageable, cacheable or 
trashable. 



Stageable objects must not be subject to frequent change or 
update. They are retained between user sessions on the system, 
provided storage space is available and the object is not dis- 
carded by a self-configuring stage algorithm, which is used to 
determine storage priority for the fixed size disk file. Over 
time, the self-configuring stage algorithm will have the effect 

© of retaining within local disk storage those objects which the 

SI 

U user has accessed most often. The objects retained locally are 

w 

58 thus optimized to each individual user's usage of the applica- 

IH tions in the system. Response time to such objects is optimized 

01 

~' since they need not be retrieved from the interactive computer 
^ system. This is done for each individual user, whose storage is 
kept separate from other users of the same personal computer 4 05 

00 

OS by using separate diskettes or separate directories on a shared 
storage medium. 

Cacheable objects can be retained during the current user 
session, but cannot be retained between sessions. These objects 
usually have a moderate update frequency. Object storage 
facility 439 retains objects in the cache according to a Least 
Recently Used (LRU) storage retention algorithm. Object storage 
facility 4 39 uses the LRU algorithm to ensure that objects that 
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are^^ast frequently used forfeit their storage to objects that 
are more frequently used. 



Trashable objects can be retained only while the user is in 
the context of the partitioned application in which the object 
was requested. Trashable objects usually have a very high update 
frequency and must not be retained to ensure that the user has 
access to the most current data. 

TBOL interpreter 438 provides the means to interpretively 

execute program objects, which have been written using an inter- 

O pretive language, TBOL (described elsewhere in this specif ica- 
M 

UJ tion) . TBOL interpreter 438 interprets operators and operands 

f& 

6| contained in program object 508, manages TBOL variables and data, 
m maintains buffer and stack facilities, and provides a run-time 

m . 

; library of TBOL verbs. 

Q 

W TBOL verbs provide support for data processing, program flow 
CO 

Ed control, file management, object management, communications , text 
display, command bar 290 control, open/close window, page naviga- 
tion and sound. TBOL interpreter also interacts with other 
native modules through commands contained in TBOL verbs. For 
example: the verb "navigate" will cause TBOL interpreter 438 to 
request object interpreter 435 to build a PPT based on the PTO-id 
contained in the operand of the NAVIGATE verb; "fetch" or "GET" 
will cause TBOL interpreter 4 38 to request an object from object 
storage facility 439; "SET_FUNCTION" will assign a filter to 
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even^^ occurring at the keyboard manger 4 34; and "FORMAT, " 
"SEND," and "RECEIVE" will cause TBOL interpreter 438 to send 
application-level requests to object/communications manager 
interface 433. 

Data areas managed by TBOL interpreter 4 38 and available to 
TBOL programs are Global External Variables (GEVs) , Partition 
External Variables (PEVs) , and Runtime Data Arrays (RDAs) . 

GEVs contain global and system data, and are accessible to 
all program objects as they are executed. GEVs provide a means 
O by which program objects may communicate with other program 
W objects or with the RS native code, if declared in the program 

m 

CO object.- GEVs are character string variables that take the size 

H 3 

fjl of the variables they contain. GEVs may preferably contain a 

7 maximum of 32,000 variables and are typically used to store such 

fl 

J*j information as program return code, system date and time, or user 

fti 

■Jr sex or- 

03 

CO age. TBOL interpreter 4 38 stores such information in GEVs when 
requested by the program which initiated a transaction to obtain 
these records from the RS or user's profile stored in the inter- 
active system. 

Partition external variables (PEVs) have a scope restricted 
to the page partition on which they are defined. PEVs are used 
to hold screen field data such that when PEOs and window objects 
are defined, the fields in the page partitions with which these 
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obj^ps are to be associated are each assigned to a PEV. When 
applications are executed, TBOL interpreter 438 transfers data 
between screen fields and their associated PEV. When the con- 
tents of a PEV are modified by user action or by program direc- 
tion, TBOL interpreter makes a request to display manager to 
update the screen field to reflect the change. PEVs are also 
used to hold partition specific application data, such as tables 
of information needed by a program to process an expected screen 
input . 

Because the scope of PEVs is restricted to program objects 
O associated with the page partition in which they are defined, 
W data that is to be shared between page partitions or is to be 
HJ available to a page-level processor must be placed in GEVs or 
U| RDAs . 

H RDAs are internal stack and save buffers used as general 

program work areas. RDAs are dynamically defined at program 
object "run-time" and are used for communication and transfer of 
data between programs when the data to be passed is not amenable 
to the other techniques available. Both GEVs and RDAs include, 
in the preferred embodiment, 8 integer registers and 8 decimal 
registers. Preferably, there also 9 parameter registers limited 
in scope to the current procedure of a program object. 



03 



All variables may be specified as operands of verbs used by 
the virtual machine. The integer and decimal registers may be 
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spe<^^ied as operands for traditional data processing- The 
parameter registers are used for passing parameters to "called" 
procedures* The contents of these registers are saved on an 
internal program stack when a procedure is called, and are 
restored when control returns to the "calling" procedure from the 
" cal led" procedure . 

TBOL interpreter, keyboard manger 4 34, object interpreter 

435, and object storage facility 439, together with device 

control provided by operating environment 450, have principal 

responsibility for the management and execution of partitioned 

P applications at the RS 400. The remaining native code modules 

W function in support and ancillary roles to provide RS 4 00 with 
CO 

03 the ability display partitioned applications to the user (display 

!»& 

pi manager 461), display advertisements (ad manager 432), to collect 

m 

g usage data for distribution to interactive network 10 for purpos- 
~t es of targeting such advertisements (data collection manager 

5 

' s jjf 4 66) , and prepare for sending, and send, objects and messages to 
05 interactive network 10 (object/communications manager interface 
433 and link communications manager 444) Finally, the fatal 
error manager exists for one purpose: to inform the user of RS 
400 and transmit to interactive network 10 the inability of RS 
4 00 to recover from a system error. 



Display manager 461 interfaces with a decoder using the 
North American Presentation Level Protocol Syntax (NAPLPS) , a 
standard for encoding graphics data, or text code, such as ASCII, 
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whic^^re displayed on the monitor of the user's personal comput- 
er 4 05 as pictorial codes* Codes for other presentation media, 
such as audio, can be specified by using the appropriate type 
code in the presentation data segments. Display manager 4 61 
supports the following functions: send NAPLPS strings to the 
decoder; echo text from a PEV; move the cursor within and between 
fields; destructive or non-destructive input field character 
deletion; "ghost" and "un-ghost" fields (a ghosted field is 
considered unavailable, un-ghosted available) ; turn off or on the 
current field cursor; open, close, save and restore bit-maps for 
a graphics window; update all current screen fields by displaying 

P the contents of their PEVs, reset the NAPLPS decoder to a known 
N 

ty state; and erase an area of the screen by generating and sending 

m 

05 NAPLPS to draw a rectangle over that area. Display manager 4 61 
jjfl also provides a function to generate a beep through an interface 
with a machine-dependent sound driver, 

few? 

SI 

flJ Ad manager 4 32 is invoked by object interpreter 4 35 to 

03 return the object-id of the next of the next available advertise- 
rs 

ment to be displayed. Ad manager 432 maintains a queue of 
advertisement object-id's targeted to the specific user currently 
accessing interactive network 10. Advertisement objects 510 are 
pre-fetched from interactive system 10 from a personalized queue 
of advertisements that is constructed using data previously 
collected from user generated events and/or reports of objects 
used in the building of pages or windows, compiled by data 
collection manager 466 and transmitted to interactive system 10, 
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^^^dvertisement objects 510 are PEOs that, through user 
invocation of a "LOOK" command, cause navigation to partitioned 
applications that may themselves support, for example, ordering 
and purchasing of merchandise. 

An advertisement list, or "ad queue," is requested in a 
transaction message to delivery system 20 by ad manager 4 32 
immediately after the initial logon response. The logon applica- 
tion at RS 400 places the advertisement list in a specific RS 
global storage area called a SYS_GEV (system global external 
variable) , which is accessible to all applications as well as to 

R the native RS code) . The Logon application also passes the first 
M 

W two ad object-id's to object storage facility 4 39 to be request- 
I ed. At logon, no advertisement objects will be available RS 
iff local storage facilities 440, so they must be requested from 

m 

- interactive system 10. 

I KS? 

1^ In a preferred embodiment, the following parametric values 

5® are established for ad manager 432: advertisement queue capaci- 
ty, replenishment threshold for advertisement object-id's and 
replenishment threshold for number of outstanding pre-fetched 
advertisement objects. These parameters are set up in GEVs of 
the RS virtual machine by the logon application program object 
from the logon response from high function system 110. The 
parameters are then also accessible to the ad manager 432. 
Preferred values are an advertisement queue capacity of 15, 
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rep]jJ^Lshment value of 10 empty queue positions and a pre- fetched 
advertisement threshold of 3 . 

Ad manager 432 pre-fetches advertisement object 510 by 

passing advertisement object-id's from the advertisement queue to 

object storage facility 4 39 which then retrieves the object from 

the interactive system if the object is not available locally. 

Advertisements are pre-f etched, so they are available in RS local 

store 44 0 when requested by object-id by object interpreter 43 5 

while it is building a page. The Ad manager 432 pre-fetches 

additional advertisement objects whenever the number of pre-f etc- 

p. hed advertisements, not used by object interpreter 435 falls 

W below the pre-fetch advertisement threshold. 
C3 

m 



yl Whenever the advertisement queue has more empty positions 

than replenishment threshold, a transaction is made to the 
/gj advertisement queue application in high function system 110 via 

J| object/communications manager interface 433 for a number of 

■M 

*9 advertisement object-id's equal to the threshold. A response 
message includes a list of advertisement object-id's, which ad 
manager 4 32 enqueues. 

Object interpreter 435 requests the object-id of the next 
advertisement from ad manager 4 32 when object interpreter 4 35 is 
building a page and encounters an object call for a partition and 
the specified object-id equals the code word, "ADSLOT." If this 
is the first request for an advertisement object-id that ad 
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mana^^ 4 32 has received during this user's session, ad manager 
4 32 moves the advertisement list from the GEV into its own 
storage area, which it uses as an advertisement queue and sets up 
its queue management pointers, knowing that the first two adver- 
tisement objects have been pre- fetched. 

Ad manager 4 32 then queries object storage facility 4 39, 
irrespective of whether it was the first request of the session. 
The query asks if the specified advertisement object id pre-fetch 
has been completed, i.e., is the object available locally at the 
RS. If the object is available locally, the object-id is passed 
p to object interpreter 435, which requests it from object storage 

W facility 439. If the advertisement object is not available in 

CO 

£0 local store 44 0, ad manager 4 32 attempts to recover by asking 

H- 

UJ about the next ad that was pre-f etched. This is accomplished by 
ffi 

m swapping the top and second entry in the advertisement queue and 
3 making a query to object storage facility 4 39 about the new top 

f advertisement object-id. If that object is not yet available, 

63 

03 the top position is swapped with the third position and a query 
is made about the new top position. 



Besides its ability to provide advertisements that have been 
targeted to each individual user, two very important response 
time problems have been solved by ad manager 432 of the present 
invention. The first is to eliminate from the new-page response 
time the time it takes to retrieve an advertisement object from 
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the t system. This is accomplished by using the aforemen- 
tioned pre-f etching mechanism. 



The second problem is caused by pre-f etching , which results 
in asynchronous concurrent activities involving the retrieval of 
objects from interactive system 10. If an advertisement is 
pre- fetched at the same time as other objects required for a page 
requested, the transmission of the advertisement object packets 
could delay the transmission of the other objects required to 
complete the current page by the amount of time required to 
transmit the advertisement object(s). This problem is solved by 

23 the structuring the requests from object interpreter 435 to the 

W ad manager 43 2 in the following way: 



m 

m 
o 

M 



1. Return next object-id of pre-f etched 

advertisement object & pre-f etch another; 

2. Return next advertisement object-id only; 

3. Prefetch next advertisement object only. 

By separating the function request (1) into its two compo- 
nents, (2) and (3), object interpreter 43 5 is now able to deter- 
mine when to request advertisement object-id's and from its 
knowledge of the page build process, is able to best determine 
when another advertisement object can be pre-f etched, thus 
causing the least impact on the page response time. For example, 
by examining the PPT, object interpreter 4 35 may determine 
whether any object requests are outstanding. If there are 
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out^pnding requests, advertisement request type would be used. 
When all requested objects are retrieved, object interpreter 435 
then issues an Advertisement request type 3, Alternatively, if 
there are no outstanding requests, object interpreter 4 35 issues 
an advertisement request type 1. This typically corresponds to 
the user's "think time" while examining the information presented 
and when RS 4 00 is in the Wait for Event state (D) . 

Data collection manager 466 is invoked by object interpreter 
4 35 and keyboard manger 4 34 to keep records about what objects a 
user has obtained (and, if a presentation data segment 530 is 

S present, seen) and what actions users have taken (e.g. "NEXT," 

IU "BACK," "LOOK," etc.) 

m 

■srxr 

jit The data collection events that are to be reported during 

cH 

* the user's session are sensitized during the logon process. The 
~ logon response message carries a data collection indicator with 
^ bit flags set to "on" for the events to be reported. These bit 

CO 

£0 flags are enabled (on) or disabled (off) for each user based on 
information contained in the user's profile stored and sent from 
high function host 110. A user's data collection indicator is 
valid for the duration of his session. The type of events to- 
be reported can be changed at will in the host data collection 
application. However, such changes will affect only users who 
logon after the change. 
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^^ata collection manager 466 gathers information concerning a 
user's individual system usage characteristics. The types of 
informational services accessed, transactions processed, time 
information between various events, and the like are collected by 
data collection manager 4 66, which compiles the information into 
message packets (not shown) . The message packets are sent to 
interactive system 10 via object/communication manager interface 
433 and link communications manager 444, Message packets are - 
then stored by high function host 110 and sent to an off-line 
processing facility for processing. The characteristics of users 
are ultimately used as a means to select or target various 
W display objects, such as advertisement objects, to be sent to 

W particular users based on consumer marketing strategies, or the 

08 

05 like, and for system optimization. 

pro 

m 

a" Object/communications manager interface 433 is responsible 

Ig for sending and receiving DIA (Data Interchange Architecture — 
Uti described elsewhere in this document) formatted messages to or 

m 

OS from interactive network 10. Object/communications manager also 

-TG. 

■« 

handles the receipt of objects, builds a DIA header for messages 
being sent and removes the header from received DIA messages or 
objects, correlates requests and responses, and guarantees proper 
block sequencing. Object/communications manager interface 433 - 
interacts with other native code modules as follows: ob- 
ject/communications manager (1) receives all RS 400 object 
requests from object storage facility 439, and forwards objects 
received from network 10 via link communications manager 444 
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dir^^ly to the requesting modules; (2) receives ad list requests 
from ad manager 432, which thereafter periodically calls ob- 
ject/communications manager to receive ad list responses; (3) 
receives data collection messages and send requests from data 
collection manager; (4) receives application-level requests from 
TBOL interpreter 438, which also periodically calls ob- 
ject/communications manager interface 433 to receive responses 
(if required) ; and (5) receives and sends DIA formatted objects 
and messages from and to link communications manager 444. 

Object/communications manager interface 4 33 sends and 
0 receives DIA formatted messages on behalf of TBOL interpreter 438 
W- and sends object requests and receives objects on behalf of 

09. 

03 object storage facility 439. Communication packets received 
|H containing parts of requested objects are passed to object 
Jf' storage facility 439 which assembles the packets into the object 
^% before storing it. If the object was requested by object inter- 

preter 435, all packets received by object storage facility 439 
IS are also passed to object interpreter 435 avoiding the delay 

required to receive an entire object before processing the 

object. Objects which are pre-f etched are stored by object 

storage facility 439. 

Messages sent to interactive system 10 are directed via DIA 
to applications in interactive system 10. Messages may include 
transaction requests for records or additional processing of 
records or may include records from a partitioned application 
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pro^^m object or data collection manager 4 66. Messages to be 
received from interactive system 10 usually comprise records 
requested in a previous message sent to interactive system 10. 
Requests received from object storage v facility 439 include 
requests for objects from storage in interactive system 10. 
Responses to object requests contain either the requested object 
or an error code indicating an error condition. 

Object/communications manager 43 3 is normally the exclusive 
native code module to interface with link communications manager 
4 44 (except in the rare instance of a fatal error) . Link commu- 



n 
M 

W of the telephone line, telephone dialing, and communications link 



nications manager 444 controls the connecting and disconnecting 



jpg data protocol. Link communications manager 444 accesses interac- 
ts 

jj| tive system 10 by means of a communications medium (not shown) 

m 

T link communications manager 444, which is responsible for a 

n 

J 55 : dial-up link on the public switched telephone network (PSTN) . 
^ Alternatively, other communications means, such as cable televi- 
E3 sion or broadcast media, may be used. Link communications 
manager 4 44 interfaces with TBOL interpreter for connect and 
disconnect, and with interactive network 10 for send and receive. 

Link communications manager 444 is subdivided into modem 
control and protocol handler units. Modem control (a software' 
function well known to the art) hands the modem specific hand- 
shaking that occurs during connect and disconnect. Protocol 
handler is responsible for transmission and receipt of data 
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pac^^s using the TCS (TRINTEX Communications Subsystem) protocol 
(which is a variety of OSI link level protocol, also well known 
to the art) . 

Fatal error manager 469 is invoked by all reception system 
components upon the occurrence of any condition which precludes 
recovery. Fatal error manager 4 69 displays a screen to the user 
with a textual message and an error code through display manager 
4 61. Fatal error manager 469 sends an error report message 
through the link communications manager 444 to a subsystem of 
interactive network 10. 

si 

y NOTE REGARDING SOURCE CODE: All of the source code for RS 4 00 is 

CO 

03 provided as part of this specification. Nomenclature for the 
yqj various service software 43 0 and 431 modules may differ, but the 
* functions described herein are implemented in the source code. 
H Some functions described herein are implemented across modules xn 

Si 

RJ source code. The following is a concordance of the terms used in 
G3 this section of the disclosure and the terms used in the source 
code : 



Specification Source Code 



Keyboard Manager = Input Manager/Event Processor 



Object Interpreter = Object Processor 
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API or Logic Interpreter 
(the above 3 modules are 
referred to as the 
Service Manager) 

Object Storage Facility = Object Manager 

Object/Communications Manager = Message Manager and 

Communications Manager 

Ad Manager 

Display Manager 

Data Collection Manager 

Communications Manager 

SOURCE CODE ORGANIZATION The source code for the reception system 
400 software is printed on the pages that follow. All files 
within each of the MS-DOS directories listed below are printed on 
sequentially numbered pages bearing the pathname of the directory 
to which they belong, 
rs 

api 
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TBO^Bnterpreter 



Ad Manager 



SI 

y Display Manager 

m 

Ul Data Collection 

s Manager 

0 

M 

in 



Link Communications 



CP 



**? Manager 



inc 



applib 



cm 



esp 



los 



oversutl 



rsk 



sm 



asm 
c 

inc 

asm 
c 

inc 

asm 
c 

inc 

asm 
c 

inc 

c 

inc 

asm 
c 

inc 
asm 



inc 

storeutl 

c 

inc 

tmk 

asm 
c 

inc 

ver_esp 

c 

inc 

ver_over 

c 

inc 

ver_sm 

c 

inc 

ver_stor 

c 

inc 




SI 

w 

09 
00 



o? 

sc. 
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SAMPLE APPLICATION 



The page illustrated in FIG. 3(b) corresponds to a parti- 
tioned application that permit's a personal computer user to 
purchase apples. It shows how the monitor screen of personal 
computer 4 05 might appear to the user. The displayed page 
includes a number of page partitions and corresponding page 
elements . 



The PTO 500 representing this page 280 is illustrated in 
FIG. 9. PTO 500 defines the composition of the page, including 
Q header 250, body 260, display fields 270, advertisement 280, and 
W command bar 290. PEOs 504 are associated with page partitions 

c g . s 

68 numbered #1, #2 and #3. They present information in the header 
yi 250, identifying the page topic as ABC APPLES; in the body 260, 
J identifying the cost of apples; and prompt the user to input into 

n 

^ fields within body 2 60 the desired number of apples to be or- 
« dered. In advertisement 280, presentation data and a field 
03 representing a post-processor that will cause the user to havi- 

y3 

gate to a targetable advertisement, is presented. 



In FIG. 9, the structure of the PTO 500 can be traced. PTO 
500 contains a page format call segment 526, which calls PFO 502. 
PFO 502 describes the location and size of partitions on the page 
and numbers assigned to each partition. The partition number is 
used in page element call segments 522 so that an association is 
established between a called PEO 504 and the page partitionwhere 
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it to be displayed. Programs attached to this PEO can be 

executed only when the cursor is in the page partition designated 
within the PEO. 



PTO 500 contains two page element call segments 522 , which 
reference the PEOs 504 for partitions #1 and #2. Each PEO 504 
defines the contents of the partition. The header in partition #1 
has only a presentation data segment(s) 530 in its PEO 504. No 
input, action, or display fields are associated with that parti- 
tion . 



O The PEO 504 for partition #2 contains a presentation data 

M 

fjj segment 53 0 and field definition segments 516 for the three 

09 

jg fields that are defined in that partition. Two of the fields 
[fl will be used for display only. One field will be used for input 

en 

of user supplied data. 

0 

FU In the example application, the PEO 504 for body partition 

CO #2 specifies that two program objects 508 are part of the body 
partition. The first program, shown in Display field 270 is 
called an initializer and is invoked unconditionally by TBOL 
interpreter 4 38 concurrently with the display of presentation 
data for the partition. In this application, the function of the 
initializer is represented by the following pseudo-code: 



1. Move default values to input and display fields; 2. 

"SEND" a transaction to the apple application that 
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P is resident on interactive system 10; 

3. "RECEIVE" the result from interactive system 10 - 

i.e. the current price of an apple; 

4. Move the price of an apple to PEV 270 number 1 so 

that it will be displayed; 

5. Position the cursor on the input field; and 

6. Terminate execution of this logic. 



The second program object 508 is a field post-processor. It 
will be invoked conditionally, depending upon the user keystroke 
input. In this example, it will be invoked if the user changes 

Q the input field contents by entering a number. The pseudo-code 

M 

W for this post-processor is as follows: 

56 

w 

H* 

l. Use the value in PEV 270 number 2 (the value associated 

i 

yS with the data entered by the user into the second input data 

s 

jp field 27 0) to be the number of apples ordered. 

SI 
fU 

m 

CQ 2. Multiply the number of apples ordered times the cost per 

apple previously obtained by the initializer; 

3. Construct a string that contains the message "THE COST OF 
THE APPLES YOU ORDERED IS $45.34;"; 



4. Move the string into PEV 270 number 3 so that the result 
will be displayed for the user; and 



Terminate execution of this logic. 

The process by which the "APPLES" application is displayed, 
initialized, and run is now discussed. 

The "APPLES" application is initiated when the user navi- 
gates from the previous partitioned application, with the naviga- 
tion target being the object-id of the "APPLES" PTO 500 (that is, 
object-id ABC1) . This event causes keyboard manager 4 34 to pass 
the PTO object-id, ABC1 (which may, for example, have been called 
by the keyword navigation segment 520 within a PEO 504 of the 
P previous partitioned application), to object interpreter 435. 
y With reference to the RS application protocol depicted in FIG. 6, 
m when the partitioned application is initiated, RS 400 enters the 
5^ Process Object state (B) using transition (1). Object interpret- 
^' er 4 35 then sends a synchronous request for the PTO 500 specified 
O in the navigation event to object storage facility 439. Object 
fU storage facility 439 attempts to acquire the requested object 
05 from local store 440 or from delivery system 20 by means of 
^object/communication manager 443, and returns an error code if 
the object cannot be acquired. 

Once the PTO 500 is acquired by object/communications 
manager 443, object interpreter 435 begins to build PPT by 
parsing PTO 500 into its constituent segment calls to pages and 
page elements, as shown in FIG. 4d and interpreting such seg- 
ments. PFO and PEO call segments 526 and 52 2 require the 
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acqu^^-tion of the corresponding objects with object-id's <ABCF>, 
<ABCX> and <ABCY>. Parsing and interpretation of object ABCY 
requires the further acquisition of program objects <ABCI> and 
<ABCJ> . 

During the interpretation of the PEOs 504 for partitions 1 and 2, 
other RS 4 00 events are triggered. This corresponds to transi- 
tion (2) to Interpret Pre-processors state (C) in FIG. 6. 
Presentation data 530 is sent to display manager 4 61 for display 
using NAPLPS decoder 476, and, as the PEO <ABCY> for partition #2 
is parsed and interpreted by object interpreter 4 35, parameters 

O in program call segment 532 identify the program object <ABCI> as 
M 

y an initializer. Object interpreter 435 obtains the program - 

f?i object from object storage facility 439, and makes a request to 

ll| TBOL interpreter 438 to execute the initializer program object 

w ' 508 <ABCI>. The initializer performs the operations specified 
^ .... 

^ above using facilities of the RS virtual machine. TBOL mter- 

r=r. 1 .... 

preter 438, using operating environment 450, executes initializer 
(*3 program object 506 <ABCI>, and may, if a further program object 
508 is required in the execution of the initializer, make a 
synchronous application level object request to object storage 
facility 439. When the initializer terminates, control is 
returned to object interpreter 435, shown as the return path in 
transition (2) in FIG. 6. 



Having returned to the Process Object state (B) , object 
processor 435 continues processing the objects associated with 
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PTO ^pBCl>. Object interpreter continues to construct the PPT, 
providing RS 400 with an environment for subsequent processing of 
the PTO <ABC1> by pre-processors and post-processors at the page, 
partition, and field levels. When the PPT has been constructed 
and the initializer executed, control is returned to keyboard 
manager 434, and the RS enters the Wait For Event (E) State, via 
transition (4) , as shown in FIG, 6. 

In the Wait for Event state, the partitioned application 

waits for the user to create an event. In any partitioned 

application, the user has many options. For example, the user 

©may move the cursor to the "JUMP" field on the command bar, which 
SJ 

yj is outside the current application, and thus cause subsequent 

El 

g navigation to another application. For purposes of this example, 
In it is assumed that the user enters the number of apples he wishes 
to order by entering a digit in display field 270 number 2. 



01 



Keyboard manager translates the input from the user's 



SI 
ffl 

W 

£y keyboard or mouse, which varies according to the type of personal 
computer used, to a logical representation independent of any 
type of personal computer. Keyboard manager 4 34 saves the data 
entered by the user in a buffer associated with the current field 
defined by the location of the cursor. The buffer is indexed by 
its PEV number, which is the same as the field number assigned to 
it during the formation of the page element. Keyboard manager 
4 34 determines for each keystroke whether the keystroke co- 
rresponds to an input event or to an action or completion event. 
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Inpi^^svents are logical keystrokes and are sent by event proces- 
sor 454 to display manager 437, which displays the data at the 
input field location. Display manager 4 37 also has access to the 
field buffer as indexed by its PEV number. 

The input data are available to TBOL interpreter 438 for 

subsequent processing. When the cursor is in a partition, only 

the PEVs for that partition are accessible to the RS virtual 

machine. After the input from the user is complete (as indicated 

by a user action such as pressing the RETURN key or entry of data 

into a field with an action attribute) , RS 400 enters the Process 

Q Event state (E) via transition (4) . 
M 

y 

ffk For purposes of this example, let us assume that that the 

y, 

jjp user enters the digit "5" in input field 3. A transition is made 
to the Process Event state (E) . Event processor 4 54 and display 
P manager 437 perform a number of actions, such as the display of 
fU the keystroke on the screen, the collection of the keystroke for 

m 

gp input, and optionally, the validation of the keystroke, i.e. 
numeric input only in numeric fields. When the keystroke is 
processed, a return is made to the Wait for Event state (D) . Ed- 
it attributes are specified in the field definition segment. 

Suppose the user inputs a "6" next. A transition occurs to 
the PE state and after the "6" is processed, the Wait for Event 
(D) state is re-entered. If the user hits the "completion" key 
(e.g., ENTER) the Process Event (E) state will be entered. The 
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act:^^ attributes associated with field 3 identify this as a 
system event to trigger post-processor program object <ABCJ>. 
When the interpretive execution of program object <ABCJ> is 

'< <y 

J ? ' complete, the Wait for Event state (D) will again be entered. 
J/tfuL 6 The user is then free to enter another value in the input field, 
or select a command bar function and exit the apples application. 



At Page 57, after Line 2, add the following pages of Source Code, 
which for convenience have been collected in 36 sections, each 
identified at the upper right hand corner of the first page of 
each section and consecutively numbered beginning at "1" therein. 

y (Amendments to the claims begin at Page 235 of the Preliminary 

00 

gj Amendment) 



M 

PJ 

ffl 
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